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ABSTRACT 


This  thesis  examines  the  practicability  of  developing  a 
standard,  stand-alone,  computerized  contract  pricing  model  for 
contract  pricing  and  negotiations.  A  functional  description 
of  a  proposed  framework  for  a  standard,  stand-alone,  computer¬ 
ized  contract  pricing  model  is  provided.  The  results  of  data 
collected  from  a  survey  of  DLA,  Navy,  and  Marine  Corps  field 
contracting  activities  are  examined  and  the  practicability  of 
developing  such  a  model  is  analyzed. 
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I.  INTRODUCTION 


A.  PURPOSE 

The  purpose  of  this  chapter  is  to  provide  the  background 
and  methodology  leading  to  the  study  of  the  practicability  of 
developing  a  standard,  stand-alone,  computerized  contract 
pricing  model.  Along  with  the  background  and  methodology,  the 
thesis  objective,  research  questions,  scope,  assumptions,  and 
limitations  are  stated. 

B.  BACKGROUND 

Developing  a  price  proposal  using  the  "stubby  pencil" 
method  can  be  both  cumbersome  and  time  consuming.  A 
negotiator  would  have  an  extreme  advantage  if  equipped  with  a 
personal  computer  that  provided  a  computerized  pricing  tool  to 
make  quick  recalculations  of  an  opponent's  position,  as  well 
as  his  own. 

Advanced  technology  in  the  form  of  personal  computers 
already  exists  at  field  contracting  activities.  However, 
standard  software  and  a  standard,  computerized  contract 
pricing  model  for  use  on  personal  computers  when  negotiating 
with  industry  do  not  exist  for  the  Navy.  Even  with  the 
advantage  of  personal  computers  at  their  fingertips,  many 
activities  are  not  using  these  powerful  tools  to  their  full 
potential.  Instead,  most  of  the  people  in  contracting  and 
negotiation  positions  use  wide  varieties  of  software  to  drive 
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individually  or  locally  developed  models  and  spreadsheets  that 
are  tailored  specifically  to  the  activity  or  contracts  at 
hand. 

Therefore,  the  idea  of  a  standard,  stand-alone,  computer¬ 
ized,  contract  pricing  model  has  tremendous  potential.  A 
menu-driven  software  package  based  on  a  standard  model  that 
calculates  contract  prices  and  fail-back  positions  would  be 
extremely  advantageous  because  the  price  analyst  and 
negotiator  would  not  have  to  "reinvent  the  wheel"  when 
preparing  price  proposals  and  conducting  price  negotiations. 
Virtually  anyone  in  a  pricing  or  contracting  position  would  be 
able  to  apply  it  successfully.  With  this  tool  available,  the 
contract  negotiator  would  be  able  to  almost  instantaneously 
recalculate  the  current  negotiated  position  in  relation  to  a 
predetermined  negotiation  range  and  the  contractor's  price 
proposal . 

Currently,  there  are  Beta  Test  models  of  the  Weighted 
Guidelines  Method  (WGL) ,  for  calculating  profit  in  accordance 
with  FAR  215.970,  and  Spreadsheet  Triangulares  (SST) ,  for 
calculating  probabilities  of  achieving  given  cost  estimates, 
written  for  LOTUS  1-2-3  by  Mr.  Dale  McNabb,  Associate  Director 
of  Small  Business,  Deputy  Chief  of  Staff  for  Contracting, 
Headquarters  Air  Force  Systems  Command.  These  models  are 
available  to  the  Department  of  Defense  and  are  being 
distributed  by  the  National  Contract  Management  Association. 


The  author  spoke  with  Mr.  McNabb  and  discussed  the  idea  of 
a  standard,  stand-alone,  computerized  contract  pricing  model. 
Mr.  McNabb  was  enthusiastic  about  the  idea  and  concurred  with 
the  theory  of  combining  his  WGL  model  with  the  author's 
proposed  model  into  a  single,  standard,  stand-alone, 
computerized  contract  pricing  model  that  would  calculate  all 
cost  elements  and  provide  the  total  price  of  a  contract, 
yielding  a  minimum,  objective  and  maximum  position,  as  well  as 
the  contractor's  position,  and  the  calculation  of  a  current 
negotiated  position. 

A  model  that  incorporated  the  features  of  Mr.  McNabb 's  WGL 
model,  plus  additional  features,  into  a  standard,  stand-alone, 
computerized  contract  pricing  model  would  be  a  very  helpful 
tool  for  Department  of  Defense  contracting  personnel.  If 
adopted,  the  model's  contribution  would  save  time  and  money 
because  man-hours  could  be  devoted  to  price  analysis  and 
negotiating,  which,  in  turn,  would  lead  to  increased 
efficiency,  decreased  backlogs  of  work  and  a  reduction  in 
costs  based  on  increased  efficiency. 

C.  OBJECTIVE 

The  purpose  of  this  thesis  is  to  examine  the  practicabili¬ 
ty  of  developing  a  standard,  stand-alone,  computerized 
contract  pricing  model  for  contract  pricing  and  negotiations. 
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D.  METHODOLOGY 


A  survey  of  Defense  Logistics  Agency  (DLA) ,  Navy,  and 
Marine  Corps  field  contracting  activities  was  conducted  to 
find  out  if  any  are  currently  using  a  computerized  contract 
pricing  model.  A  questionnaire  was  also  used  to  gain  feedback 
on  what  kind  of  software  is  being  used  and  to  ascertain  if  a 
standard,  stand-alone,  computerized  contract  pricing  model 
would  be  of  interest  to  them. 

E .  RESEARCH  QUESTIONS 

1.  Primary  Question 

What  is  the  practicability  of  developing  a  standard, 
stand-alone,  computerized  contract  pricing  model  that  will  be 
used  as  a  decision  support  system  for  contract  pricing  and 
negotiations? 

2 .  Subsidiary  Questions 

Do  DLA,  Navy  or  Marine  Corps  field  contracting  offices 
currently  have  computerized  contract  pricing  models  that 
they  are  using? 

Do  defense  contractors  currently  have  computerized 
contract  pricing  models  within  their  companies  that  they 
are  using? 

What  elements  should  comprise  a  standard,  stand-alone, 
computerized  contract  pricing  model  and  what  functions 
should  it  perform? 

F.  SCOPE,  ASSUMPTIONS,  AND  LIMITATIONS 

The  main  thrust  of  the  thesis  will  be  to  examine  the 
practicability  of  developing  a  standard,  stand-alone, 
computerized  contract  pricing  model  that  can  be  programmed  as 
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a  menu-driven  software  package  using  any  brand  of  software. 
The  focus  will  be  on  feasibility  and  practicality. 

The  author  assumes  the  reader  has  a  general  working 
knowledge  of  contract  pricing  and  negotiations.  Therefore, 
contract  pricing  and  negotiation  theory  will  be  omitted. 

Firm  Fixed-Price  (FFP)  contracts  will  be  used  to  present 
a  functional  description  of  the  proposed  framework  for  a 
standard,  stand-alone,  computerized  contract  pricing  model. 
The  model  will  be  based  on  the  basic  cost  elements  of  a  FFP 
contract  as  found  in  the  Armed  Services  Pricing  Manual  [Ref. 
1] .  Those  elements  are: 

Direct  Materials; 

Direct  Labor; 

-  Other  Direct  Costs; 

Indirect  Costs; 

Profit. 

FFP  contracts  will  be  used  because  they  have  fewer 
variables  to  consider  when  conducting  contract  pricing  and 
negotiations . 

G.  THESIS  ORGANIZATION 

Chapter  I  provides  background,  the  thesis  objective, 
methodology,  research  questions,  scope,  assumptions  and 
limitations. 

Chapter  II  provides  background  information  concerning  the 
preliminary  research  that  was  conducted  and  reviews  prior 
research  done  by  others  in  this  area. 
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Chapter  III  provides  a  functional  description  of  the 
proposed  framework  for  a  standard,  stand-alone,  computerized 
contract  pricing  model. 

Chapter  IV  examines  the  results  of  the  data  collected  from 
a  survey  of  DLA,  Navy,  and  Marine  Corps  field  contracting 
activities  and  analyzes  the  practicability  of  developing  a 
standard,  stand-alone,  computerized  contract  pricing  model. 

Chapter  V  answers  the  research  questions  and  renders 
conclusions  and  recommendations. 

H.  SUMMARY 

This  chapter  provided  background  information  and  the 
objective  of  the  thesis.  The  methodology  leading  to  the  study 
of  the  practicability  of  developing  a  standard,  stand-alone, 
computerized  contract  pricing  model  was  stated,  along  with  the 
research  questions,  scope,  assumptions,  and  limitations. 

The  next  chapter  provides  background  information 
concerning  the  preliminary  research  that  was  conducted  and 
presents  a  review  of  prior  research  that  is  specifically 
related  to  this  thesis'  area  of  research. 


6 


II.  PRELIMINARY  RESEARCH 


A.  PURPOSE 

The  purpose  of  this  chapter  is  to  provide  background 
information  concerning  the  preliminary  research  that  was 
conducted  and  to  present  a  review  of  prior  research  in  this 
area  of  research. 

B.  BACKGROUND 

Initially,  the  Defense  Contract  Administration  Services 
Management  Area  (DCASMA) ,  San  Francisco,  was  contacted  to 
ascertain  if  they  use  a  standard,  computerized  contract 
pricing  model.  One  did  not  exist.  Each  price  analyst  was 
using  some  sort  of  individually  developed  spreadsheet  tailored 
to  each  contract.  Furthermore,  to  the  best  of  the  DCASMA' s 
knowledge,  no  standard  model  existed  within  the  Department  of 
Defense  (DOD) . 

Next,  the  Naval  Regional  Contracting  Center  (NRCC) , 
Philadelphia,  Pennsylvania  [Ref.  2],  and  NRCC,  Washington, 
D.C.  [Ref.  3]  were  contacted  to  see,  again,  if  such  a  model  is 
used.  Neither  NRCC  had,  or  knew  of,  such  a  model.  They,  too, 
use  individually  or  locally  developed  spreadsheets  tailored  to 
each  contract,  each  driven  by  a  wide  variety  of  software. 

Next,  the  Fleet  Material  Support  Office  (FMSO) , 
Mechanicsberg,  Pennsylvania  [Ref.  4],  was  contacted  to  see  if 
such  a  model  was  currently  in  development.  FMSO  was  contacted 
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because  they  are  the  central  design  agency  for  the  Navy's 
inventory  control  points  and  many  of  their  software-driven 
systems.  They  are  not  currently  developing  a  contract  pricing 
model,  nor  do  they  have  plans  to  do  so  in  the  near  future. 
Furthermore,  they  were  unaware  of  any  previous  attempt  to 
develop  such  a  model. 

Aware  of  a  model  written  for  LOTUS  1-2-3  that  calculates 
profit  using  the  WGL  method,  Mr.  McNabb  [Ref.  5],  the 
programmer  of  the  WGL  model ,  was  contacted  and  the  idea  of  a 
standard,  stand-alone,  computerized  contract  pricing  model  was 
discussed.  Mr.  McNabb  was  enthusiastic  about  the  idea  and 
concurred  with  the  theory  of  combining  his  WGL  model  with  the 
author's  proposed  model  into  a  single,  standard,  stand-alone, 
computerized  contract  pricing  model  that  would  calculate  all 
cost  elements  and  produce  the  total  price  of  a  contract, 
yielding  a  minimum,  objective  and  maximum  position,  as  well  as 
the  contractor's  position,  and  the  calculation  of  the  current 
negotiated  position. 

Once  the  idea  of  a  standard,  stand-alone,  computerized 
contract  pricing  model  that  combined  Mr.  McNabb 's  WGL  model 
with  the  author's  proposed  model  was  formulated,  preliminary 
research,  with  the  assistance  of  the  Dudley  Knox  Library 
Readers  Services  at  the  U.S.  Naval  Postgraduate  School, 
Monterey,  California,  was  conducted  by  performing  a  series  of 
computer  searches  for  similar  models  and  research  in  that 
area. 
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Searches  of  the  Defense  Systems  Management  College  (DSMC) 
database,  the  Defense  Technical  Information  Center  (DTIC) 
database,  the  National  Technical  Information  Service  (NTIS) 
database,  the  Information  Services  for  Physics,  Electronics 
and  Computing  (INSPEC)  database,  and  the  thesis  and  research 
database  at  the  Naval  Postgraduate  School  did  not  produce  any 
reports  that  were  related  specifically  to  the  area  of 
research. 

A  computer-based  search  was  conducted  with  assistance  from 
the  Defense  Logistics  Studies  Information  Exchange  (DLSIE) 
from  their  database,  located  at  the  U.S.  Army  Logistics 
Management  College,  Fort  Lee,  Virginia.  Three  relevant 
references  were  found  from  this  literature  search.  The 
following  are  the  reports  retrieved  from  the  DLSIE  database 
that  are  specifically  related  to  the  area  of  research. 

1 .  COPPER  IMPACT  Guidebook:  Applications  of  Automation 
to  Contract  Pricing  and  Finance 

Sponsored  and  written  in  1978  by  the  Air  Force  Systems 
Command,  Andrews  AFB,  Maryland,  this  handbook  provides 
information  and  guidance  on  the  COPPER  IMPACT  project  which 
was  initiated  to  improve  the  pricing  process  in  the  Air  Force. 
COPPER  is  an  Air  Force  code  word  for  contracting  projects, 
while  IMPACT  is  an  acronym  for  the  objective  to  "improve 
modern  pricing  and  cost  techniques."  This  project  focuses  on 
personnel  training  and  retention  and  increasing  the  level  of 
sophistication  in  the  process  through  selective  and  cost- 
effective  application  of  a  time-sharing  computer.  The  main 
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objective  of  the  project  is  to  introduce  computer  technology 
to  the  contract  pricing  function  as  a  medium  for  implementa¬ 
tion  of  advanced  analytical  information  processing  and 
management  techniques. 

2 .  COPPER  IMPACT:  Computer  Technology  Applied  to 
Contract  Pricing 

This  report  was  sponsored  by  the  Florida  Institute  of 
Technology  and  was  written  in  1980  by  James  E.  Gustine,  John 
A.  Mills,  and  Charles  R.  Thompson  of  the  Florida  Institute  of 
Technology.  In  1980,  the  U.S.  Army  research  and  development 
community,  specifically  the  U.S.  Army  Materiel  Development  and 
Readiness  Command  (DARCOM) ,  began  to  use  time-shared  computer 
applications  in  their  contract  pricing.  The  objective  of  this 
report  is  to  describe  COPPER  IMPACT  and  to  relate  its  applica¬ 
bility  to  the  DARCOM  efforts  to  use  time-shared  computer 
applications  in  contract  pricing. 

3 •  Report  on  the  Feasibility  of  Designing  Expert  Systems 
For  Contract  Price  Analysis 

This  research  was  sponsored  by  the  Air  Force  Business 
Research  Management  Center,  Wright-Patterson  Air  Force  Base 
(AFB)  ,  Ohio.  The  report  was  written  in  1983  by  Dr.  B. 
Chandrasekaran,  Dr.  J.  Dillard,  Dr.  T.  Harrison,  and  Dr.  K. 
Ramakrishna  of  Ohio  State  University.  It  discusses  the 
feasibility  of  designing  an  expert  system  for  contract  price 
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analysis.  A  prototype  design  in  the  ZOG1  information 
management  system  is  also  presented.  The  system  architecture 
and  the  organization  of  pricing  knowledge  in  the  system  was 
determined  by  field  investigations. 

A  final  piece  of  literature  that  was  discovered  in  a 
separate  literature  search  was  the  article,  "Contracting 
Office  Information  Systems:  A  Key  to  Defense  Acquisition 
Improvement,"  which  appeared  in  the  February  1990  issue  of 
Contract  Management .  the  professional  journal  of  the  NCMA. 
This  article  discusses  the  emergence  of  contracting  automation 
technology,  presents  some  current  examples  of  DOD  procurement 
related  automated  systems,  surfaces  some  problem  areas,  and 
addresses  positive  trends. 

C.  PRIOR  RESEARCH 

1.  COPPER  IMPACT 

During  the  late  1960's  and  early  1970's  the  Air  Force 

procurement  community  had  considerable  concerns.  The 

principal  concerns  were  [Ref.  6:p.  1-1]: 

The  increasing  complexity  of  weapon  systems  which  was 
leading  to  serious  cost  growth  problems; 

Cost  growth  problems  were  undermining  public  and 
Congressional  confidence  in  Air  Force  management  of  the 
procurement  process; 


’ZOG  is  not  an  abbreviation.  The  name  was  selected  for 
its  ease  of  pronunciation  and  novelty,  and  is  intended  to 
suggest  that  ZOG  is  a  novel  system  for  human-computer 
interactions.  The  ZOG  system  was  developed  at  Carnegie-Mellon 
University,  supported  by  the  Office  of  Naval  Research. 
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National  resources  were  beginning  to  be  allocated  to 
projects  other  than  defense,  causing  a  scarcity  of 
funds ; 

Budget  cuts,  weapon  system  complexity  and  Congressional 
acts,  such  as  Public  Law  87-653,  Truth  in  Negotiations, 
created  a  need  for  increased  detail  in  data  and  analysis 
associated  with  establishing  weapon  contract  prices. 

In  late  1971  [Ref.  6:p.  1-2],  the  Director  of  Air 
Force  Procurement  Policy,  then  Brigadier  General  R.F.  Trimble, 
responded  to  these  concerns  by  initiating  a  project,  COPPER 
IMPACT,  to  Improve  Modern  Pricing  and  Costing  Techniques.  The 
project  was  approved  by  the  Air  Force  Chief  of  Staff  on  9  May 
1972  [Ref.  6:p.  1-2]. 

The  objective  of  COPPER  IMPACT  was  to  improve  the  Air 
Force's  ability  to  procure  what  it  needed  at  realistic,  fair 
and  reasonable  prices.  The  approach  was  to  enlarge  and  refine 
the  judgment-making  capacity  of  professional  procurement 
pricing  personnel.  This  would  be  done  by  streamlining  the 
administrative  and  mechanical  tasks  in  the  pricing  process. 
This  would  provide  the  analyst  with  more  time,  information, 
and  techniques  to  accomplish  the  primary  pricing  objective  of 
obtaining  the  best  price  for  the  Government. 

During  1972  [Ref.  6:p.  1-2],  the  primary  goal  was  to 
develop  the  automated  system  necessary  to  support  the 
objectives  of  COPPER  IMPACT.  Time-sharing  computers  had  been 
used  in  field  pricing  activities  successfully  since  1969  [Ref. 
6:p.  1-2]  in  applying  the  overhead  cost  forecasting  technique 
known  then  as  PIE-COST  (Probability  of  Incurring  Estimated 
Cost) .  The  decision  to  merge  PIE-COST  into  the  COPPER  IMPACT 
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project  was  made  in  late  1972  [Ref.  6:p.  1-2].  This  merger 
formed  the  nucleus  of  the  network  of  time-sharing  computer 
users  involved  in  contract  pricing  and  financial  analysis. 
The  resulting  system  provided  for  the  development  of  cost 
proposal  simulation  models,  data  banks  of  pricing  information, 
such  as  labor  and  overhead  rates,  and  analytical  programs, 
such  as  regression  analysis.  The  program  is  written  in  the 
FORTRAN  programming  language  for  implementation  on  a  General 
Electric  (GE)  Time  Share  computer  using  the  GE-Timeshare 
operating  system. 

Cost  models  contain  logic  simulation  which  can  model 
any  contractor's  proposal  by  simulating  the  proposal's 
inherent  logical  buildup  and  cost  relationships.  The  analyst, 
using  this  model,  can  quickly  audit  the  proposal,  compute  a 
negotiation  objective  based  on  the  results  of  his  analysis, 
recompute  a  position  during  negotiations  and  present  all  cost 
proposal  analysis  in  formatted  hard-copy  spreadsheets.  These 
models  permit  the  analyst  to  perform  sensitivity  analysis 
through  the  use  of  a  series  of  model  runs.  Then,  determina¬ 
tion  of  which  cost  elements  drive  the  bottom  line  price  can  be 
accomplished.  "The  various  cost  models  have  shown  a  savings 
from  8:1  to  10:1  in  terms  of  man-hours  consumed  in  pricing 
computations  and  report  operations,  while  being  very  useful  in 
all  aspects  of  the  pricing  process."  [Ref.  7:p.  4] 

There  are  three  types  of  cost  models  available  [Ref. 

7 :p.  3]: 


13 


Generalized  Cost  Model  (GCM) ; 

Programmable  Cost  Model  (PCM) ; 

-  Management  of  Overhead  Discrete  Evaluation  (MODE) . 

GCM  permits  the  user  to  construct  a  model  of  a 
specific  proposal  without  knowledge  of  any  programming 
language.  Its  main  utility  is  in  reducing  the  time  required 
to  program  the  model  in  BASIC  or  FORTRAN. 

The  purpose  of  PCM  is  identical  to  GCM,  but  it  uses  an 
approach  where  the  user  interacts  conversationally  with  the 
program  when  defining  the  model  and  putting  data  in.  COPPER 
IMPACT  users  have  programmed  many  specialized  models  to  apply 
to  specific  cost  proposal  formats  from  different  contractors. 

MODE  examines  the  overhead  cost  flow  from  initial  cost 
occurrence  to  a  final  rate  of  development  by  simulating  a 
specific  contractor's  cost  accounting  system.  Settled 
Overhead  Retrieval  Technique  (SORT)  complements  MODE  by 
providing  the  Administrative  Contracting  Officer  (ACO)  data  on 
final  settlement  findings  by  various  contract  administrative 
activities  over  the  last  three  years.  This  model  helps  lend 
to  the  consistency  of  the  treatment  of  overhead  rates. 

In  addition  to  cost  models,  COPPER  IMPACT  provides 
four  other  major  applications: 

Workload  Management; 

Data  Banks? 

-  Analysis  Aids; 

Financial  Data  Retrieval  and  Analysis  System  (FINANDAS) . 
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Workload  management  provides  local  management,  inter¬ 
nal  management  and  higher  headquarters  visibility  of  caseload 
and  management  information  to  assist  in  resource  allocation 
decisions,  overall  management  decisions,  and  policy  decisions. 

The  primary  data  bank  application  in  COPPER  IMPACT  is 
the  centralized  pricing  rate  and  factor  data  bank,  CONRATES. 
The  time-sharing  computer  allows  for  central  storing, 
maintaining,  and  retrieval  of  information  by  users  at  widely 
dispersed  locations. 

In  addition  to  the  previously  mentioned  applications, 
COPPER  IMPACT  provides  numerous  ways  to  assist  in  the  analysis 
of  large  quantities  of  data.  Statistical  analysis,  curve¬ 
fitting,  regression,  correlation,  learning  curves,  cash  flow, 
and  present  value  analysis  are  some  of  the  examples  of  the 
analysis  aids  available. 

FINANDAS  is  a  recent  addition  to  COPPER  IMPACT.  It 
has  the  capability  of  obtaining  and  analyzing  financial 
statements  of  major  defense  contractors.  The  system  was 
developed  by  the  Logistics  Management  Institute  (LMI)  under 
the  sponsorship  of  DOD,  Director  of  Contracts  and  Systems. 
FINANDAS  stores  financial  statements  from  up  to  900  defense 
contractors.  If  the  contractor's  financial  statement  is  not 
stored,  FINANDAS  has  the  capability  of  analyzing  the  financial 
statement  if  the  data  are  entered  by  the  user.  Stored  data 
are  obtained  from  Standard  and  Poor's  Compustat  Services,  Inc. 
and  includes  133  elements  of  audited  annual  financial  data. 
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five-year  financial  statements,  historical  trends,  several 
ratio  reports,  and  the  capability  to  produce  five-year 
projections.  [Ref.  7:p.  6] 

COPPER  IMPACT  met  the  expectations  of  the  Air  Force's 
program  and  was  expanded  in  subsequent  years  with 
sophisticated  applications  and  models.  Since  1974  [Ref.  7:p. 
2],  other  government  agencies  in  DoD  have  become  subscribers 
to  the  program. 

The  Army  became  interested  in  the  computer  time-shared 
technique  of  contract  pricing  for  the  same  reasons  as  the  Air 
Force.  Army  Materiel  Command  (AMC)  placed  three  computer 
terminals  on-line  with  the  COPPER  IMPACT  network  in  July  1977 
[Ref.  7:p.  2].  These  were  located  in  the  Missile  Command, 
Tank- Automotive  Command,  and  Armaments  Material  Readiness 
Command.  Since  that  time  the  service  has  been  expanded  to  11 
terminals  which  provide  time-shared  capability  with  all  major 
subordinate  commands  of  AMC  and  two  AMC  offices  located  in 
major  defense  contractors'  plants. 

2 .  Time-share  Computer  Systems 

A  time-share  computer  system  is  one  which  organizes 
and  directs  multiple  access  to  a  single  central  processing 
unit.  Through  the  use  of  telephone  communication  equipment, 
the  user  can  be  away  from  the  location  of  the  central 
computer. 

There  are  five  general  areas  that  time-share  computer 
systems  have  application  in: 
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Data  Banks; 

Overhead  Management  ? 

Cost  Models; 

Workload  Management; 

Statistical  Analysis. 

Some  time-share  programs  currently  written  are 
discussed  below  [Ref.  8:p.  24]. 

a.  A  Systematic  Numerical  Analysis  of  Proposals 
Program  (ASNAPP) 

ASNAPP  allows  comparison  of  up  to  six  different 
cost  proposals  against  one  base.  It  calculates  cost  element 
variances  and  prints  formatted  reports. 

b.  Proposal/Position  Comparison  Program  (POPICOP) 
POPICOP  calculates  and  displays  the  contractor's 

proposal,  the  corresponding  Government  estimate,  and  the 
computation  of  variances  between  the  two. 

c.  WGL 

This  program  generates  a  Weighted  Guidelines 
Profit  Objective  consistent  with  the  DoD  Profit  Policy. 

3 .  Report  on  the  Feasibility  of  Designing  Expert  Systems 

for  Contract  Price  Analysis 

This  is  a  technical  report  containing  conclusions 
about  the  feasibility  of  "expert  systems"  for  price  analysis. 
The  report  also  analyzes  contract  pricing.  Problems 

associated  with  price  analysis  during  procurement  are 
identified  as  well. 
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The  design  of  a  prototype  in  an  information  base 
called  XINFO2  is  then  presented.  Some  of  the  problems  with 
this  design  are  discussed.  A  proposed  redesign  using  another 
information  base  called  ZOG  is  provided,  along  with  how  an 
expert  system  could  improve  performance  among  both  trained  and 
untrained  personnel . 

The  focus  of  this  study  was  the  development  of  a 
prototype  version  of  an  " intelligent"  computer  system  designed 
to  aid  in  price  analysis.  An  "intelligent"  system  is  an 
interactive  computer  system  that  does  not  have  problem-solving 
capabilities,  but  is  intended  to  guide  a  user  to  performing  at 
an  expert  level. 

The  model  was  designed  to  perform  all  aspects  of  price 
analysis  as  described  in  the  ASPM-1.  The  main  objective  was 
to  construct  a  system  that  could  be  used  by  an  unskilled, 
inexperienced  analyst  to  make  complex  calculations,  thereby 
greatly  assisting  in  the  procurement  process,  as  well  as 
potentially  saving  the  Government  large  sums  of  money. 

The  simplest  level  is  an  on-line  reference  manual  that 
would  point  the  user  to  information  that  might  be  needed.  The 
second  level,  similar  to  COPPER  IMPACT,  could  provide 
spreadsheet  capability  that  would  help  collect  and  manipulate 
data  as  well  as  offer  simulation  models.  The  next  level 


2This  is  not  an  abbreviation.  The  name  is  intended  to 
suggest  that  it  is  an  extended  information  base.  The  XINFO 
system  was  developed  at  the  Massachusetts  Institute  of 
Technology. 
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provides  a  series  of  questions  and  answers  to  assist  the  user 
in  using  information  stored  in  a  database.  A  structured  trace 
of  the  user  responses  to  the  questions  can  be  used  to 
construct  a  descriptive  model  of  the  contractor's  bid.  The 
highest  and  most  sophisticated  level  is  capable  of 
constructing  normative  models  of  the  contractor's  bid  based  on 
the  descriptive  models. 

The  conclusions  at  the  time  of  the  report  were 
basically  two-fold.  The  expert  system  was  too  cumbersome  at 
the  time,  but  its  potential  usefulness  warranted  further 
research. 

4 .  The  Institute  for  Defense  Analyses  Cost  Research 

Symposium 

The  Institute  for  Defense  Analysis  (IDA) ,  Alexandria, 
Virginia,  conducted  a  meeting  on  18  May  1989  to  discuss 
studies  on  cost  research.  Participants  included  the  directors 
of  offices  that  sponsor  and  conduct  defense  cost  research.  A 
report  was  prepared  by  the  Cost  Analysis  and  Research  Division 
of  IDA.  The  report  catalogues  studies  discussed  at  the 
meeting. 

The  focus  of  the  meeting  was  identification  of 
research  activities  and  information  that  were  not  otherwise 
available  through  DTIC  and  NTIS.  Studies  were  identified  that 
had  just  been  completed,  were  in  progress,  or  planned.  The 
report  contains  a  general  overview  of  the  209  research  tasks 
discussed  during  the  symposium.  About  84  percent  of  the 
studies  deal  with  some  aspect  of  cost  estimating/analysis. 
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About  14  percent  deal  with  other  techniques  for  reviewing/ 
monitoring  costs.  [Ref.  9:pp.  1-4] 

5 .  "Contracting  Office  Information  Systems:  A  Key 

to  Defense  Acquisition  Improvement" 

This  article,  written  by  James  L.  Vann,  appeared  in 

the  February  1990  issue  of  Contract  Management.  the 

professional  magazine  of  the  NCMA.  It  discusses  the  emergence 

of  contracting  automation  technology  in  three  distinct  areas: 

Powerful  microcomputer  hardware  based  on  faster  micro¬ 
processor  chips  and  operating  systems,  and  greater  memory 
and  data  storage; 

Integrated  fourth  generation  software  oriented  toward  the 
end  user; 

-  Advanced  architectures  and  protocols  for  electronic  data 
interchange  networks  and  system  connectivity. 

Some  potential  applications  are  listed  as  follows: 
Advanced  office  automation  systems; 

Integrated  database  networks; 

On-line  vendor  communications; 

On-line  regulatory  guidance; 

Interactive  computer-based  instruction; 

Decision  support  systems. 

Nine  current  DOD  procurement  related  automated  systems 
are  described. 

a.  DLA  Pre-Award  Contracting  System  (DPACS) 

This  system,  prototyped  in  1986  at  the  Defense 
Industrial  Supply  Center  in  Philadelphia,  Pennsylvania, 
automates  large-scale  supply  purchasing  operations.  It  has 
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the  capability  of  retrieving  price  histories  and  other 
purchasing  information  required  by  buyers  on  solicitations. 

b.  Paperless  Order  Placement  System  (POPS) 

Initiated  in  1983  at  the  DLA  Defense  General 

Supply  Center  in  Richmond,  Virginia,  this  system  electron¬ 
ically  places  orders  with  established  vendors  for  standard 
supply  items . 

c.  Mechanization  of  Contract  Administration  Services 
(MOCAS) 

This  system  is  the  primary  mainframe-based  system 
for  tracking  the  status  of  DC.\J  sites'  contract 
administration . 

d.  Integrated  Procurement  System  (IPS) 

This  system  enhancement  is  expected  to  replace  the 

Army  Materiel  Command's  current  contract  drafting  system, 

Procurement  Automated  Data  and  Document  System  ( PADDS ) .  Some 

of  the  systems  features  include: 

Electronic  transmission  of  requirements  and  procurement 
documents  within  the  command  matrix; 

Support  for  developing  independent  Government  cost 
estimates ; 

Electronic  transmission  of  synopses,  solicitations, 
proposals,  and  contracts. 

e.  Standard  Army  Automated  Contracting  System 
(SAACONS) 

Acquired  by  the  Army  in  1987,  this  system  has  been 
fielded  in  more  than  150  installation  contracting  offices. 
SAACONS  is  menu-driven  and  is  functionally  oriented  toward 
desktop  preparation  of  contract  documents  and  reports.  It  is 
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designed  for  non-major  systems  and  installation  level  support 
contracting. 

f.  Automation  of  Procurement  and  Accounting  Data 

Entry  (APADE) 

This  system,  maintained  by  the  Navy’s  FMSO, 
features  on-line  retrieval  of  price  histories  and  vendor 
sources,  action  status,  forms  and  report  generation,  and 
standard  item  descriptions.  Enhancements  include  word 
processing,  document  preparation,  automated  bidders  lists,  and 
bid  evaluation  packages. 

g.  Base  Contracting  Automated  System  (BCAS) 

This  Air  Force  system  for  installation 
contracting,  adopted  by  the  Marine  Corps  and  the  Defense 
Mapping  Agency  as  well,  emphasizes  electronic  transmission  and 
validation  of  requirements,  history  data,  reports  generation, 
and  updates  to  requiring  and  finance  activities. 

h.  Acquisition  Management  Information  System  (AMIS) 

This  mainframe  system  developed  by  the  Air  Force 

provides  integrated  financial  status  tracking  and  administra¬ 
tion  of  major  systems  and  related  contracts. 

i.  Contract  Data  Management  System  (CDMS) 

This  is  another  Air  Force  system  that  is  planned 
for  the  1990 's.  Its  features  are  supposed  to  include  receiv¬ 
ing  and  processing  procurement  requests,  document  preparation, 
proposal  evaluation,  price  history  retrieval,  report  genera¬ 
tion,  and  extensive  system  interconnectivity. 
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Next,  the  article  surfaces  five  problem  areas: 

Failure  to  address  contracting  needs; 

System  proliferation; 

Excessive  standardization; 

Program  cost  and  grandiosity; 

Management  coordination. 

Finally,  it  addresses  some  positive  trends.  For 
instance,  DOD  has  developed  the  Defense  Interdepartmental 
Procurement  Automation  Control  Council  (DIPACC) ,  an  office 
within  the  Secretary  of  Defense,  which  will  serve  as  an 
advisory  panel  to  the  Deputy  Assistant  Secretary  of  Defense 
(Procurement)  on  policy  matters  relating  to  the  procurement  of 
automation  systems.  Additionally,  the  Office  of  Federal 
Procurement  Policy  (OFPP)  is  sponsoring  an  interagency  task 
force  to  support  a  project  on  procurement  automation  for  the 
President's  Council  on  Management  Improvement. 

D.  SUMMARY 

This  chapter  provided  background  information  concerning 
the  preliminary  research  that  was  conducted  and  presented  a 
review  of  related  research  done  by  others  in  this  area. 

The  next  chapter  furnishes  a  functional  description  of  the 
proposed  framework  for  a  standard,  stand-alone,  computerized 
contract  pricing  model. 
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III.  THE  PROPOSED  MODEL 


A.  PURPOSE 

The  purpose  of  this  chapter  is  to  furnish  a  functional 
description  of  the  proposed  framework  for  a  standard,  stand¬ 
alone,  computerized  contract  pricing  model.  An  overview, 
methodology,  context  diagram,  and  data  flow  diagrams  are 
provided  in  order  to  understand  the  proposed  model  and  lay  the 
groundwork  for  analyzing  the  practicability  of  developing  such 
a  model. 

B.  OVERVIEW 

The  proposed  model  is  not  intended  to  be  used  for  cost/ 
price  analysis.  It  is  designed  only  to  calculate  price 
positions  relative  to  the  Government,  the  contractor,  and  the 
current  negotiated  position.  All  costs/prices  are  assumed  to 
have  been  analyzed  prior  to  being  input  into  the  model  using 
various  techniques  available. 

A  standard,  stand-alone,  computerized  contract  pricing 
model  that  calculates  contract  prices  and  fail-back  positions 
would  be  extremely  advantageous  and  has  tremendous  potential 
because  the  price  analyst  and  negotiator  would  not  have  to 
"reinvent  the  wheel"  when  preparing  price  proposals  and 
conducting  price  negotiations.  The  contract  negotiator  would 
be  able  to  almost  instantaneously  recalculate  the  current 
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negotiated  position  in  relation  to  a  predetermined  negotiation 
range  and  the  contractor's  price  position. 

C .  METHODOLOGY 

In  order  to  understand  the  information  requirements  and 
conceptualize  how  data  moves  through  the  proposed  model,  what 
processes  transform  data  and  what  the  outputs  are,  a  visual 
depiction  will  be  provided  along  with  a  narrative  description 
of  the  proposed  model.  The  presentation  of  the  proposed  model 
will  take  the  form  of  a  series  of  data  flow  diagrams  and  the 
appropriate  explanations  to  accompany  them. 

Data  flow  diagrams  are  a  graphical  representation  of  data 
movement  through  the  proposed  model.  The  data  flow  approach 
emphasizes  the  logic  underlying  the  proposed  model.  By  using 
a  combination  of  only  four  symbols,  as  depicted  in  Figure  1 
(Data  Flow  Diagram  Symbols) ,  a  pictorial  depiction  of  data 
flows  is  created. 

The  shadow-box  is  used  to  depict  an  external  entity  that 
can  give  and  receive  data  from  the  system.  The  external 
entity  is  also  called  a  source  or  destination  of  data,  and  is 
considered  to  be  external  to  the  study.  Each  external  entity 
is  labeled  with  an  appropriate  name.  Although  it  interacts 
with  the  system,  it  is  considered  as  external  to  the 
boundaries  of  the  system. 

The  arrow  shows  movement  of  data  from  one  point  to 
another,  with  the  head  of  the  arrow  pointing  toward  the  data's 
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destination.  Each  arrow  is  labeled  with  an  appropriate  data 
flow  name. 

A  regular  box  is  used  to  show  the  occurrence  of  a 
transformation  process.  Processes  always  denote  a  change  in 
or  transformation  of  data.  Hence,  the  data  flow  leaving  a 
process  is  always  labeled  differently  than  the  one  entering 
it. 

The  last  symbol  used  in  data  flow  diagrams  represents  a 
data  store  and  is  an  open-ended  rectangle.  Each  data  store  is 
labeled  with  an  appropriate  name.  In  data  flow  diagrams,  the 
type  of  physical  storage  (e.g.,  tape,  diskette,  etc.)  is  not 
specified. 

The  data  flow  approach  has  three  advantages  [Ref.  10 :p. 
249].  The  biggest  advantage  is  the  conceptual  freedom  found 
in  the  use  of  the  four  symbols.  None  of  the  symbols  specifies 
the  physical  aspects  of  implementation. 

An  additional  advantage  is  that  it  enables  the  reader  to 
better  understand  the  interrelatedness  of  the  proposed  model 
and  its  process  by  providing  a  broad  overview  and  then 
exploding  the  proposed  model  into  its  functional  subsystems. 

A  third  advantage  is  that  it  can  be  used  as  a  tool  to 
interact  with  users.  By  showing  them  representations  of  the 
proposed  model,  users  can  comment  on  the  accuracy  of  the 
conceptualization. 

Developing  the  data  flow  diagrams  was  accomplished  by 
using  the  top-down  approach.  First,  the  data  flows  were 
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conceptualized  from  a  top-down  perspective.  A  context  diagram 
was  drawn.  It  determines  the  boundaries  of  the  proposed  model 
to  be  described. 

Next  is  the  level  zero  diagram  which  is  an  overview  of 
basic  inputs,  processes,  and  outputs.  This  is  the  most 
general  diagram  and  is  a  bird's  eye  view  of  the  broadest 
possible  conceptualization  of  the  proposed  model. 

The  diagrams  move  from  general  to  specific.  More  details 
are  subsequently  added  at  levels  two  and  three  by  exploding 
the  diagrams. 

D.  CONTEXT  DIAGRAM 

The  standard,  stand-alone,  computerized  contract  pricing 
model  could  be  used  for  preparing  contract  price  proposals  or 
during  contract  price  negotiations,  as  depicted  by  the  context 
diagram  in  Figure  2  (Context  Diagram) . 

E.  DATA  FLOW  DIAGRAMS 

1.  Level  Zero 

The  level  zero  data  flow  diagram  is  depicted  in  Figure 
3  (Level  Zero) .  There  are  only  two  entities  throughout  the 
entire  proposed  model.  One  is  the  Government  contract  price 
analyst/negotiator  and  the  other  is  the  defense  contractor. 

There  are  three  basic  processes  in  the  proposed  model: 

Calculate  the  Government's  price  proposal  (Figure  3  — 
Process  1) ; 

-  Calculate  the  defense  contractor's  price  position  (Figure 
3 — Process  2) 
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Figure  3.  Level  Zero 


Calculate  the  negotiated  contract  position  (Figure  3 — 
Process  3) . 

Data  flow  through  several  paths  at  this  level. 
Cost/price  analysis  data  by  the  Government  contract  price 
analyst/ negotiator  (Figure  3 — Government  Entity)  of  the 
applicable  contract  cost  elements  (Figure  3 — Data  Store  1) 
flow  to  the  first  process  of  the  proposed  model — calculate  the 
Government's  price  proposal  (Figure  3 — Process  1).  The 
Government's  price  proposal  data  flow  to  the  contract 
negotiation  range  output  (Figure  3 — Data  Store  2) .  Negotia¬ 
tion  range  output,  .r  this  point,  are  only  the  Government's 
minimum,  objecti\e  and  maximum  starting  price  proposal 
positions.  The  information  from  the  negotiation  range  output 
(Figure  3 — Data  Store  2)  flows  back  to  the  Government  contract 
price  analyst/negotiator  (Figure  3 — Government  Entity) . 

The  defense  contractor's  (Figure  3 — Contractor  Entity) 
price  proposal  of  the  applicable  contract  cost  elements 
(Figure  3 — Data  Store  1)  flows  to  the  second  process  of  the 
proposed  model — calculate  the  defense  contractor's  price 
position  (Figure  3 — Process  2).  The  defense  contractor's 
price  position  flows  to  the  contract  negotiation  range  output 
(Figure  3 — Data  Store  2) . 

The  Government's  starting  price  proposal  (based  on 
Figure  3 — Process  1)  and  the  defense  contractor's  price 
position  (based  on  Figure  3 — Process  2)  form  the  contract 
negotiation  range  which  flows  back  to  the  Government  contract 
price  analyst/negotiator  (Figure  3 — Government  Entity)  as  the 
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contract  negotiation  range  output  (Figure  3 — Data  Store  2) . 
This  output  provides  the  Government  contract  negotiator  with 
his  minimum,  objective,  and  maximum  positions,  along  with  the 
contractor's  proposed  position. 

Then,  negotiated  cost  elements  of  counter-offers  from 
the  Government  negotiator  (Figure  3 — Government  Entity)  and 
the  defense  contractor  (Figure  3 — Contractor  Entity)  flow  to 
the  third  process  of  the  proposed  model — calculate  the 
negotiated  contract  position  (Figure  3 — Process  3) .  At  this 
point,  the  data  flow  to  the  contract  negotiation  range  output 
(Figure  3 — Data  Store  2)  and  back  to  the  Government  contract 
price  analyst/negotiator  (Figure  3 — Government  Entity) ,  where 
the  present  negotiated  position  is  displayed  alongside  of  the 
Government's  minimum,  objective,  and  maximum  positions,  and 
the  contractor's  position. 

When  this  negotiated  contract  position  is  agreed  upon 
and  the  "handshake"  occurs,  the  data  flow  to  the  negotiated 
contract  (Figure  3 — Data  Store  3)  . 

Figure  4  (Level  Zero  Output)  depicts  what  output  at 
this  level  may  look  like.  The  output  at  this  level  is 
calculated  by  combining  the  level  one  data. 

2 .  Level  One 

The  level  one  drawings  are  depicted  in  Figures  5 
(Calculate  Government  Price  Proposal) ,  6  (Calculate  Contractor 
Price  Position) ,  and  7  (Calculate  Negotiated  Contract 
Position) .  At  this  level,  calculation  of  the  Government's 
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D1  Coot  Elements  2  C«  lou  lets  Contractor  Price  Position 
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Fiaure  6.  Calculate  Contractor  Price  Position 


Cakajhftto  N#gottart»d  Prloo  Pot  ft  Ion 


Figure  7.  Calculate  Negotiated  Contract  Position 


contract  price  proposal,  the  defense  contractor's  price 
position,  and  the  negotiated  contract  position  are  all 
performed  by  five  subsystems: 

-  Calculate  Direct  Materials  (Figure  5 — Process  1.1) (Figure 
6 — Process  2.1) (Figure  7 — Process  3.1); 

Calculate  Direct  Labor  (Figure  5 — Process  1.2) (Figure  6 
— Process  2.2) (Figure  7 — Process  3.2); 

Calculate  Other  Direct  Costs  (Figure  5 — Process  1.3) 
(Figure  6 — Process  2.3) (Figure  7 — Process  3.3); 

Calculate  Indirect  Costs  (Figure  5 — Process  1.4) (Figure 
6 — Process  2.4) (Figure  7 — Process  3.4); 

Calculate  Profit  (Figure  5 — Process  1.5) (Figure  6 — 
Process  2.5) (Figure  7 — Process  3.5). 

The  output  at  this  level  would  look  the  same  as  the 
output  for  level  zero  (Figure  4 — Level  Zero  Output) ,  but  is 
calculated  from  level  two  data  input. 

3 .  Level  Two 

At  this  level,  the  five  subsystems  that  calculate  the 
Government's  contract  price  proposal,  the  defense  contractor's 
price  position,  and  the  negotiated  contract  position  are 
exploded  into  their  own  subsystems. 

Since  the  calculation  processes  for  the  five  level  one 
subsystems  (Figure  5 — Processes  1.1,  1.2,  1.3,  1.4,  &  1.5) 

(Figure  6 — Processes  2.1,  2.2,  2.3,  2.4,  &  2.5)  (Figure  7  — 

Processes  3.1,  3.2,  3.3,  3.4,  &  3.5)  are  the  same  for  the 

Government's  contract  price  proposal,  the  defense  contractor's 
price  position,  and  the  negotiated  contract  position,  only  the 
data  flow  diagrams  for  the  calculation  of  the  Government's 
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contract  price  proposal  will  be  portrayed  (Figure  3 — Process 
1)  • 

a.  Calculate  Direct  Materials  (Figure  8 — Process 

1.1) 

Calculation  of  direct  materials  is  performed  by 
five  subsystems,  as  depicted  in  Figure  8  (Calculate  Direct 
Materials) : 

Calculate  Raw  Materials  (Figure  8 — Process  1.1.1); 

Calculate  Subcontracted  Items  (Figure  8 — Process  1.1.2); 

Calculate  Standard  Items  (Figure  8 — Process  1.1.3); 

Calculate  Interorganizational  Transfers  (Figure  8 — 

Process  1.1.4); 

Calculate  Purchased  Parts  (Figure  8 — Process  1.1.5). 

The  output  for  each  of  the  five  subsystems  (Figure 
8 — Processes  1.1.1,  1.1.2,  1.1.3,  1.1.4,  1.1.5)  within  the 

process  of  calculating  direct  materials  (Figure  8 — Process 
1.1)  is  derived  from  level  three  data  input.  The  output  for 
the  process  of  calculating  direct  materials  is  calculated  by 
adding  the  totals  of  the  five  subsystems  (Figure  8 — Processes 
1.1.1,  1.1.2,  1.1.3,  1.1.4,  1.1.5)  within  the  direct  materials 
subsystem  (Figure  8 — Process  1.1). 

Figure  9  (Direct  Materials  Output)  depicts  what 
the  output  that  the  user  would  receive  from  the  direct 
materials  subsystem  (Figure  8 — Process  1.1)  may  look  like. 

For  example,  the  total  minimum  costs  of  raw 
materials,  subcontracted  items,  standard  items, 
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Figure  8.  Calculate  Direct  Materials  (Process 
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interorganizational  transfers,  and  purchased  parts  are  added, 
yielding  the  total  minimum  cost  for  direct  materials. 

b.  Calculate  Direct  Labor  (Figure  10 — Process  1.2) 

Calculation  of  direct  labor  is  performed  by  two 
subsystems,  as  depicted  in  Figure  10  (Calculate  Direct  Labor) : 

Calculate  Factory  Labor  (Figure  10 — Process  1.2.1); 

-  Calculate  Engineering  Labor  (Figure  10 — Process  1.2.2). 

The  output  for  each  subsystem  (Figure  10 — 
Processes  1.2.1  &  1.2.2)  within  the  process  of  calculating 
direct  labor  (Figure  10 — Process  1.2)  is  derived  from  level 
three  input ,  The  output  for  the  direct  labor  subsystem 
(Figure  10 — Process  1.2)  is  calculated  by  multiplying  the 
direct  labor  rates  from  level  three  by  the  estimated  direct 
labor  hours  from  level  three  and  then  summing  the  data. 

Figure  11  (Direct  Labor  Output)  depicts  what  the 
output  that  the  user  would  receive  from  the  direct  labor 
subsystem  may  look  like. 

For  example,  the  minimum  direct  labor  rates  for  a 
particular  labor  category  from  level  three  are  multiplied  by 
the  minimum  estimated  direct  labor  hours  for  that  category 
from  level  three.  The  objective,  maximum,  contractor,  and 
negotiated  direct  labor  are  calculated  in  the  same  manner. 
This  process  is  repeated  for  each  direct  labor  category. 
Then,  the  individual  direct  labor  category  costs,  as  calcu¬ 
lated  above,  are  summed,  thereby  providing  total  minimum, 
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Figure  10.  Calculate  Direct  Labor  (Process 
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objective,  maximum,  contractor,  and  negotiated  direct  labor 
costs . 

c.  Calculate  Other  Direct  Costs  (Figure  12 — Process 

1.3) 

Calculation  of  other  direct  costs  is  performed  by 
an  unprescribed  number  of  subsystems,  as  depicted  in  Figure  12 
(Calculate  Other  Direct  Costs) .  Examples  of  other  direct 
costs  are  tooling,  special  insurance,  travel  expenses, 
preservation,  packaging  and  packing,  plant  rearrangement, 
start-up  costs,  consultant's  fees,  certain  clerical  salaries, 
shop  supplies,  transportation  costs,  plant  protection, 
royalties,  excise  taxes,  computer  expenses,  and  telephone  and 
telegraph  expenses  [Ref.  l:p.  5-59], 

The  output  at  this  level  is  calculated  by  adding 
total  other  direct  costs  (Figure  12 — Processes  1.3.1,  1.3.2, 
1.3.3,  1.3.4,  1.3.5,  &  1.3.X)  from  level  three  data  input. 

Figure  13  (Other  Direct  Costs  Output)  depicts  a 
possible  output  that  the  user  may  receive  from  the  other 
direct  cost  subsystem. 

For  example,  total  minimum  tooling,  total  minimum 
operating  expense,  total  minimum  tires  and  tubes,  total 
minimum  oil  and  grease,  and  total  minimum  equipment  rental 
would  be  added  yielding  the  total  minimum  other  direct  cost. 

d.  Calculate  Indirect  Costs  (Figure  14 — Process 

1.4) 

Calculation  of  indirect  costs  is  performed  by  an 
unprescribed  number  of  subsystems,  as  depicted  in  Figure  14 
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Figure  12.  Calculate  Other  Direct  Costs  (Process 
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Figure  14.  Calculate  Indirect  Costs  (Process 


(Calculate  Indirect  Costs) .  Indirect  costs  can  be  comprised 
of  an  unlimited  number  of  overhead  expense  pools.  Overhead 
expense  pools,  other  than  those  depicted,  include,  but  are  not 
limited  to,  scrap,  spoilage,  defective  items,  handling,  and 
carrying  costs. 

The  output  for  each  subsystem  (Figure  14 — 
Processes  1.4.1,  1.4.2,  1.4.3,  1.4.4,  &  1.4.X)  within  the 
process  of  calculating  indirect  costs  (Figure  14 — Process  1.4) 
is  derived  from  level  three  input. 

The  output  for  the  overhead  subsystem  is 
calculated  by  multiplying  the  overhead  rates  from  level  three 
by  the  estimated  overhead  bases  from  level  three  and  then 
summing  the  data. 

For  example,  the  minimum  overhead  rates  for  a 
particular  overhead  category  from  level  three  are  multiplied 
by  the  minimum  estimated  overhead  base  for  that  category  from 
level  three.  The  objective,  maximum,  contractor,  and 
negotiated  overhead  are  calculated  in  the  same  manner.  This 
process  is  repeated  for  each  overhead  category.  Then,  the 
individual  overhead  category  costs,  as  calculated  above,  are 
summed,  thereby  providing  total  minimum,  objective,  maximum, 
contractor,  and  negotiated  overhead  costs. 

General  and  administrative  costs  are  either  input 
directly  or  they  are  calculated  by  multiplying  the  appropriate 
base,  as  derived  from  level  three,  by  the  applicable  rate, 
thereby  producing  general  and  administrative  costs. 
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Finally,  the  material  overhead,  factory  labor 
overhead,  engineering  overhead,  general  and  administrative 
expenses,  and  other  indirect  costs  are  summed,  thereby 
providing  total  indirect  costs. 

Figure  15  (Indirect  Costs  Output)  depicts  what 
the  output  that  the  user  would  receive  from  the  indirect  cost 
subsystem  may  look  like. 

For  example,  the  minimum  material  overhead, 
minimum  factory  labor  overhead,  minimum  engineering  overhead, 
and  minimum  general  and  administrative  costs  are  added, 
yielding  total  minimum  indirect  costs. 

e.  Calculate  Irofit  (Figure  16 — Process  1.5) 

Calculation  of  profit  is  performed  by  two 
subsystems,  as  depicted  in  Figure  16  (Calculate  Profit) : 

Weighted  Guidelines  Method  (Figure  16 — Process  1.5.1); 

Profit  Base  Method  (Figure  16 — Process  1.5.2). 

The  user  may  utilize  one  or  both  methods  for 
calculating  profit. 

The  output  for  the  process  of  calculating  profit 
using  the  weighted  guidelines  method  (Figure  16 — Process 
1.5.1)  is  derived  in  accordance  with  DFARS  Part  215,  Subpart 
215.9 — Profit.  This  output  would  be  produced  five  separate 
times  from  the  level  three  data  input,  in  order  to  yield  the 
minimum,  objective,  maximum,  contractor,  and  negotiated  profit 
positions . 
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Figure  16.  Calculate  Profit  (Process 


The  output  for  the  process  of  calculating  profit 
using  the  profit  base  method  (Figure  16 — Process  1.5.2)  is 
derived  by  taking  the  profit  base  from  level  three  and 
multiplying  it  by  the  applicable  rate,  thereby  producing  the 
total  profit. 

Figures  17  (Weighted  Guidelines  Output)  and  18 
(Profit  Base  Output) ,  the  weighted  guidelines  method  and  the 
profit  base  method,  respectively,  depict  what  the  output  that 
the  user  would  receive  from  the  profit  subsystem  may  look 
like. 

For  example,  the  minimum  profit  base  is  multiplied 
by  the  minimum  percentage  of  profit,  giving  the  minimum  total 
profit. 

4 .  Level  Three 

This  is  the  level  where  the  "rubber  meets  the  road," 
so  to  speak.  It  is  at  this  level  where  the  majority  of  the 
data  input  for  the  contract  is  made. 

a.  Calculate  Raw  Materials  (Figure  19-Process  1.1.1)  , 
Subcontracted  Items,  Standard  Items,  Interorgani- 
zational  Transfers,  and  Purchased  Parts 

Figure  19  (Calculate  Raw  Materials)  depicts  the 

calculation  of  raw  materials.  Calculation  of  subcontracted 

items,  standard  items,  interorganizational  transfers,  and 

purchased  parts  would  be  similar,  therefore  they  are  not 

shown.  This  process  (Figure  19 — Process  1.1.1)  is  performed 

by  an  unprescribed  number  of  subsystems  (Figure  19 — Processes 

1.1. 1.1,  1.1. 1.2,  1.1. 1.3,  &  l.l.l.X).  Subsystems,  other  than 
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Figure  19.  Calculate  Raw  Materials  (Process 


those  depicted,  include,  but  are  not  limited  to,  scrap  rates, 
handling  costs,  carrying  costs,  and  learning  curves  (Figure  19 
— Process  l.l.l.X). 

Specific  line  item  labels  (Figure  19 — Process 
1.1. 1.1)  are  assigned  for  each  raw  material,  subcontracted 
item,  standard  item,  interorganizational  transfer,  and 
purchased  part.  The  total  number  of  units  required  is  entered 
(Figure  19 — Process  1.1. 1.2).  There  will  be  a  minimum, 
objective,  maximum,  contractor,  and  negotiated  cost  per  unit 
input  corresponding  to  each  label  (Figure  19 — Process 
1.1. 1.3)  . 

Costs  per  unit  are  multiplied  by  the  total  number 
of  units  required,  yielding  total  costs  for  each  line  item. 
These  line  item  total  costs  will  then  be  added,  thereby 
yielding  total  raw  material,  subcontractor  item,  standard 
item,  interorganizational  transfer,  and  purchased  parts  costs. 

Figure  20  (Raw  Materials  Output)  depicts  what 
output  for  raw  materials  at  this  level  may  look  like.  Output 
for  subcontractor  items,  standard  items,  interorganizational 
transfers,  and  purchased  parts  would  be  similar. 

For  example,  the  minimum  cost  per  unit  of  material 
A  would  be  multiplied  by  the  total  units  required  for  material 
A,  thereby  producing  the  minimum  total  cost  for  material  A. 
The  minimum  total  costs  for  materials  B,  C,  and  D  would  be 
calculated  in  the  same  manner.  Then,  the  minimum  total  costs 
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for  materials  A,  B,  C,  and  D  would  be  added.  The  sum  would  be 
the  total  minimum  raw  materials  cost. 

b.  Calculate  Factory  (Figure  21 — Process  1.2.1)  and 

Engineering  Labor 

Figure  21  (Calculate  Factory  Labor)  depicts  the 
calculation  of  factory  labor.  Calculation  of  engineering 
labor  would  be  similar,  therefore  it  is  not  shown.  The 
process  (Figure  21 — Process  1.2.1)  is  performed  by  an 
unprescribed  number  of  subsystems  (Figure  21 — Processes 
1.2. 1.1,  1.2. 1.2,  1.2. 1.3,  &1.2.1.X).  Subsystems,  other  than 
those  depicted,  include,  but  are  not  limited  to,  learning 
curves,  level  of  effort,  historical  data,  labor  standards,  and 
plant  condition  factors  (Figure  21 — Process  1.2.1.X). 

Specific  labor  category  labels  (Figure  21 — Process 
1.2. 1.1)  are  assigned  for  each  kind  of  labor.  There  will  be 
a  minimum,  objective,  maximum,  contractor,  and  negotiated  wage 
per  hour,  or  salary  per  period,  input  corresponding  to  each 
label  (Figure  21 — Process  1.2. 1.2).  Figure  22  (Labor  Rates 
Output)  depicts  what  output  at  this  level  may  look  like. 

There  will  be  a  minimum,  objective,  maximum, 
contractor,  and  negotiated  estimated  labor  hours,  or  estimated 
number  of  salary  periods,  input  corresponding  to  each  label 
(Figure  21 — Process  1.2. 1.3).  These  labor  hour  estimates  can 
then  be  added  to  yield  the  total  labor  hours  for  the  entire 
contract.  Figure  23  (Estimated  Labor  Hours  Output)  depicts 
what  output  at  this  level  may  look  like. 
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Figure  21.  Calculate  Factory  Labor  (Process 
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MINIMUM  OBJECTIVE  MAXIMUM  CONTRACTOR  NEGOTIATED 
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The  minimum,  objective,  maximum,  contractor,  and 
negotiated  estimated  labor  hours  for  each  labor  category 
(Figure  23 — Estimated  Labor  Hours)  are  multiplied  by  their 
respective  labor  rates  for  each  category  (Figure  22 — Labor 
Rates) ,  thereby  producing  labor  costs  for  each  labor  category 
(Figure  ll — Direct  Labor) . 

c.  Calculate  Tooling  (Figure  24 — Process  1.3.1), 

Operating  Expenses,  Tires  and  Tubes,  Oil  and 

Grease,  Equipment  Rental,  and  Other  Direct  Costs 

Figure  24  (Calculate  Tooling)  depicts  the 
calculation  of  tooling  costs.  Calculation  of  the  other  direct 
expenses  within  the  other  direct  cost  subsystem  (Process  1.3) 
would  be  similar,  therefore  they  are  not  shown.  This  process 
(Figure  24 — Process  1.3.1)  is  performed  by  two  subsystems 
(Figure  24 — Processes  1.3. 1.1  &  1.3. 1.2),  as  depicted. 

Specific  other  direct  cost  labels  are  assigned  for 
each  kind  of  other  direct  cost  (Figure  24 — Process  1.3. 1.1). 
There  will  be  a  minimum,  objective,  maximum,  contractor,  and 
negotiated  cost  input  corresponding  to  each  label  (Figure  24 — 
Process  1.3. 1.2).  These  line  item  costs  will  then  be  added, 
thereby  yielding  total  other  direct  costs,  such  as  tooling, 
operating  expenses,  tires  and  tubes,  oil  and  grease,  and 
equipment  rental. 

Figure  25  (Tooling  Costs  Output)  depicts  what 
output  for  tooling  costs  at  this  level  may  look  like. 

For  example,  the  minimum  costs  for  jigs,  dies, 
fixtures,  and  test  equipment  would  be  added  to  yield  the  total 
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Figure  24.  Calculate  Tooling  (Process 
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minimum  cost  for  tooling.  Likewise,  the  minimum  costs  to 
operate  two  trucks  and  two  generators  would  be  added  to  yield 
the  total  minimum  direct  cost  for  operating  expenses,  and  so 
on. 

d.  Calculate  Material  (Figure  26 — Process  1.4.1), 

Factory  and  Engineering  Overhead,  and  General  and 

Administrative  Expense  Bases 

Figure  26  (Calculate  Material  Overhead)  depicts 
the  calculation  of  material  overhead.  Calculation  of  factory 
and  engineering  overhead,  general  and  administrative  expenses, 
and  other  indirect  costs  would  be  similar,  therefore  they  are 
not  shown.  This  process  (Figure  26 — Process  1.4.1)  is 
performed  by  two  subsystems  (Figure  26 — Processes  1.4. 1.1  & 
1.4. 1.2)  . 

There  will  be  a  minimum,  objective,  maximum, 
contractor,  and  negotiated  rate  input  for  each  type  of 
indirect  cost  (Figure  26 — Process  1.4. 1.1). 

The  material  (Figure  26 — Process  1.4. 1.2), 
factory,  and  engineering  overhead  bases  are  derived  from  the 
totals  depicted  in  Figures  9  (Direct  Materials)  and  11  (Direct 
Labor)  respectively. 

The  general  and  administrative  expense  base  is 
derived  from  Figure  4  (Level  Zero  Output)  by  adding  total 
direct  costs  to  total  overhead  costs. 

Figure  27  (Material  Overhead  Output)  depicts  what 
output  for  material  overhead  costs  at  this  level  may  look 
like. 
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Figure  26.  Calculate  Material  Overhead  (Process 
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The  bases  for  the  other  indirect  cost  pools 
(Processes  1.4.2,  1.4.3,  1.4.4,  &  1.4.X)  are  calculated  by 
adding  the  applicable  expenses.  For  example,  the  base  for 
scrap  and  spoilage  may  be  derived  from  the  sum  of  only 
materials  A  and  B  (Figure  20 — Raw  Materials) . 

e.  Calculate  Weighted  Guidelines  Method  (Figure  28) 

The  Weighted  Guidelines  Method  (Figure  28) 
requires  the  application  of  DD  Form  1547.  The  Weighted 
Guidelines  Method  is  described  and  calculated  in  accordance 
with  DFARS  215.970. 

A  minimum,  objective,  maximum,  contractor,  and 
negotiated  value  is  required  for  each  applicable  input  in 
order  to  produce  the  five  separate  outputs  as  described  in 
Section  E.3  of  this  chapter  (Figure  16 — Process  1.5.1). 

For  example,  the  minimum  materials,  subcontracts, 
direct  labor,  indirect  expenses  (less  general  and  administra¬ 
te  . e  expenses),  other  direct  costs,  and  general  and  adminis¬ 
trative  expenses  are  derived  from  level  two  output.  Next, 
minimum  performance  risk,  contract  type  risk,  and  working 
capital  are  determined  in  accordance  with  the  designated 
ranges  as  described  in  DFARS  215.970.  Then,  in  accordance 
with  DFARS  215.970,  the  total  minimum  profit  objective  is 
calculated.  This  process  would  be  repeated  for  the  objective, 
maximum,  contractor,  and  negotiated  positions  as  well. 
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DO  Form  1547,  AUG  *7 


Figure  28.  Calculate  Weighted  Guidelines  Method 
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f.  Calculate  Profit  Base  (Figure  16 — Process  1.5.2) 
The  profit  base  is  the  total  cost  of  the  contract 
and  is  derived  from  Figure  4  (Level  Zero  Output)  by  adding 
total  direct  costs  and  total  indirect  costs. 

F.  SUMMARY 

This  chapter  furnished  the  reader  with  a  functional 
description  of  the  proposed  framework  for  a  standard,  stand¬ 
alone,  computerized  contract  pricing  model.  An  overview  of 
the  proposed  model  was  presented.  Next,  it  addressed  the 
methodology  used  to  present  the  proposed  model.  Then,  a 
visual  depiction  was  provided  along  with  a  narrative 
description  of  the  proposed  model  using  a  top-down  approach — 
a  Context  Diagram  followed  by  Level  Zero  through  Level  Three 
Data  Flow  Diagrams. 

The  next  chapter  examines  the  results  of  the  data 
collected  from  a  survey  of  DLA,  Navy,  and  Marine  Corps  field 
contracting  activities  and  analyzes  the  practicability  of 
developing  the  proposed  model. 


IV.  ANALYSIS 


A.  PURPOSE 

The  purpose  of  this  chapter  is  to  analyze  the 
practicability  of  developing  the  standard,  stand-alone, 
computerized  contract  pricing  model,  as  it  was  presented  in 
Chapter  III.  An  overview  of  the  survey  study,  the  survey 
sample,  survey  responses,  the  questionnaire,  results  of  the 
analysis  of  survey  responses,  statistical  inferences,  and  a 
practicability  analysis  are  provided. 

B.  OVERVIEW  OF  THE  SURVEY  STUDY 

A  survey  of  DLA,  Navy,  and  Marine  Corps  field  contracting 
activities  was  conducted  to  find  out  if  any  of  them  are 
currently  using  a  contract  pricing  model.  The  questionnaire 
was  also  used  to  gain  feedback  on  software  currently  used  and 
to  see  if  they  would  be  interested  in  a  standard,  stand-alone, 
computerized  contract  pricing  model. 

Survey  results  were  mixed.  Many  field  activities  are 
using  some  sort  of  a  model.  Others  are  using  spreadsheet 
techniques.  All  activities  are  utilizing  a  variety  of 
software. 

Many  field  activities  were  quite  enthusiastic  about  the 
prospect  of  the  proposed  model. 

On  the  other  hand,  some  field  activities  felt  that  it  is 
not  practical,  or  even  feasible,  to  develop  a  standard. 
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stand-alone,  computerized  contract  pricing  model,  since 
contract  types  and  their  corresponding  proposals  are 
different,  cost  elements  vary  so  much  from  contract  to 
contract,  and  cost  accounting  systems  are  so  diverse. 

It  was  perceived  that  some  contracting  activities  have  not 
pursued  developing  a  standard  model  because  of  normal  workload 
requirements  and  the  fact  that  spreadsheets  have  been  the  most 
adaptable  application  of  suiting  their  needs. 

C.  SURVEY  SAMPLE 

A  total  of  143  questionnaires  were  sent  to  all  major  DLA, 
Navy,  and  Marine  Corps  field  contracting  activities.  Of  the 
143  questionnaires,  80  were  sent  to  Defense  Contract  Adminis¬ 
tration  Services  Management  Area  (DCASMA)  and  Defense  Contract 
Administration  Services  Plant  Representative  Office  (DCASPRO) 
activities,  51  were  sent  to  Navy  field  contracting  activities, 
and  12  were  sent  to  Marine  Corps  field  contracting  activities. 

D.  SURVEY  RESPONSES 

The  response  to  the  survey  was  as  follows: 

Seventy-four  activities  replied; 

One  activity  was  a  duplicate  address; 

Five  surveys  were  "returned  to  sender." 
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This  means  that  the  net  number  of  activities  surveyed  was 
1371 .  Therefore,  there  was  a  total  combined  response  rate  of 
542  percent. 

More  specifically,  of  the  80  DCASMA  and  DCASPRO  activities 
surveyed,  38  replied  and  five  were  returned  to  sender.  The 
net  number  of  DLA  activities  surveyed,  therefore,  was  753,  and 
the  individual  response  rate  for  DCASMA  and  DCASPRO  activities 
was  50. 74  percent. 

Of  the  51  Navy  field  contracting  activities  surveyed,  28 
replied  for  an  individual  response  rate  of  54.9s  percent. 

Finally,  of  the  12  Marine  Corps  field  contracting 
activities  surveyed,  eight  replied  and  one  was  a  duplicate 
address.  The  net  number  of  Marine  Corps  activities  surveyed, 
therefore,  was  11,  with  an  individual  response  rate  of  72.7s 
percent 
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The  DLA  share  of  the  total  response  was  51. 47  percent.  The 
Navy  share  of  the  total  response  was  37.8®  percent.  And,  the 
Marine  Corps  share  of  the  total  response  was  10.8®  percent. 


TABLE  1 

RESPONSE  RATES 


Activity 

Surveyed 

Number 

Surveyed 

Number 

Responded 

Individual 

Response 

Rate 

Total 

Response 

Rate 

DLA 

75 

38 

50.7% 

51.4% 

Navy 

51 

28 

54.9% 

37.8% 

Marines 

11 

8 

72.7% 

10.8% 

Net  Sample 

137 

74 

N/A 

54.0% 

E.  QUESTIONNAIRE 

The  field  contracting  activities  surveyed  were  asked  the 
following  questions: 

Does  your  activity  have  a  computerized  pricing  model? 

If  so,  what  software  runs  the  model? 

Was  the  model  developed  in-house? 

If  so,  who  developed  the  model? 

If  the  model  was  not  developed  in-house,  who  developed 
it? 

Does  your  activity  use  the  pricing  model  in  developing 
price  proposals  and  during  price  negotiations  both? 


738/74  =  .5135 
*28/74  =  .3784 
*8/74  =  .1081 
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If  so,  is  the  model  currently  used  by  your  activity 
adequate  for  all  you  activity's  price  proposal  and  price 
negotiation  needs?  If  not,  why  not? 

If  your  activity  is  not  using  the  pricing  model  for  both 
price  proposals  and  negotiations,  is  your  activity  using 
the  pricing  model  only  to  prepare  price  proposals? 

If  so,  when  your  negotiators  receive  a  counter-proposal 
during  negotiations,  do  your  negotiators  manually 
calculate  their  positions?  If  not,  how  do  they  calculate 
their  position  then? 

If  your  activity  is  not  using  the  pricing  model  just  for 
price  proposals,  are  you  using  your  pricing  model  just 
for  negotiations?  If  so,  how  are  your  price  proposals 
developed? 

Does  your  activity  use  the  pricing  model  for  any  other 
applications  besides  proposals  and  price  negotiations? 
If  so,  what? 

If  your  activity  does  not  currently  have  a  computerized 
pricing  model,  have  they  ever  used  one  before?  If  not, 
why  not? 

If  so,  which  computerized  pricing  model  did  they  use? 
Why  did  they  stop  using  it? 

If  your  activity  does  not  have  a  computerized  pricing 
model,  does  your  activity  use  a  computerized 
spreadsheet? 

If  not,  how  does  your  activity  prepare  price  proposals 
and  how  do  your  negotiators  calculate  their  positions 
during  negotiations? 

If  your  activity  does  use  a  computerized  spreadsheet, 
what  software  is  your  activity  using? 

Does  your  activity  use  the  computerized  spreadsheet  in 
developing  price  proposals  and  during  negotiations  both? 

If  your  activity  is  not  using  its  computerized  spread¬ 
sheet  for  both  price  proposals  and  negotiations,  is  your 
activity  using  the  spreadsheet  only  to  prepare  price 
proposals? 

If  so,  when  your  negotiators  receive  a  counter-proposal 
during  negotiations,  do  your  negotiators  manually 
calculate  their  positions?  If  not,  how  do  they  calculate 
their  position  then? 
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If  your  activity  is  not  using  the  computerized  spread¬ 
sheet  just  for  price  proposals,  are  you  using  your 
spreadsheet  just  for  negotiations?  If  so,  how  are  your 
price  proposals  developed? 

Does  your  activity  use  the  spreadsheet  for  any  other 
applications  besides  price  proposals  and  price 
negotiations?  If  so,  what? 

Is  the  computerized  spreadsheet  currently  used  by  your 
activity  adequate  for  all  your  activity's  price  proposal 
and  price  negotiation  needs?  If  not,  why  not? 

Would  your  activity  be  interested  in  a  standard  pricing 
model?  If  not,  why  not? 

Additionally,  the  activities  were  asked  to  send  a  copy  of 
their  models  and  computerized  spreadsheets,  along  with  any 
other  documentation  and  formulations  they  deemed  appropriate. 


F .  RESULTS 

The  results  of  the  analysis  of  survey  responses  follow. 
Each  question  is  addressed  individually  below. 

1 •  Does  Your  Activity  Have  a  Computerized  Pricing 

Model? 

Computerized  pricing  models  are  used  by  37  activities, 
or  5010  percent  of  those  surveyed.  Some  activities  have  more 
than  one  model.  Some  activities  require  different  models  for 
different  contractors.  Sometimes,  activities  require  several 
models  for  the  same  contractor  because  they  use  them  for 
different  divisions  or  on  separate  contracts. 

2 .  If  So.  What  Software  Runs  the  Model? 

The  37  activities  that  have  models  use  a  variety  of 
software  to  run  the  models.  The  majority  of  the  models  are 

1037/74  =  .5 
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run  using  LOTUS  1-2-3.  Specifically,  19  out  of  37,  or  51.4" 
percent  of  activities  that  have  models,  use  LOTUS  1-2-3 
version  2.01  or  later  to  run  their  models.  Out  of  3  7 
activities  that  have  models,  six,  or  16. 212  percent,  use  Enable 
to  run  their  models.  Out  of  37  activities  that  have  models, 
five,  or  13. 513  percent,  use  both  LOTUS  1-2-3  and  Enable  to  run 
their  models.  Out  of  37  activities  that  have  models,  four,  or 
10. 814  percent,  use  Symphony  (a  LOTUS  product)  to  run  their 
models.  Only  three  out  of  37,  or  8 . 115  percent  of  activities 
that  have  models,  use  some  other  type  of  software  to  run  their 
models . 


TABLE  2 

SOFTWARE  CURRENTLY  RUNNING  MODELS 


Software 

Number 

Percent 

LOTUS  1-2-3 

19 

51.4 

Enable 

6 

16.2 

Both  LOTUS  &  Enable 

5 

13.5 

Symphony 

4 

10.8 

Other  Software 

3 

8.1 

"19/37  =  .5135 
,26/37  =  .  1621 
135/37  =  .  1351 
144/37  =  .1081 
153/37  =  .  0811 
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3 .  Was  the  Model  Developed  In-house? 


Almost  all  of  the  models  were  developed  in-house. 
Specifically,  30  out  of  37,  or  81. 116  percent,  of  the  models 
were  developed  in-house. 

4 .  If  So.  Who  Developed  the  Model? 

All  of  the  models  that  were  developed  in-house  were 
developed  by  a  cost/price  analyst  or  someone  from  the 
financial  services  branch  of  the  activity. 

Out  of  the  30  models  that  were  developed  in-house,  17, 
or  56. 717  percent,  were  developed  by  a  single  individual,  while 
the  other  13,  or  43. 318  percent,  were  developed  as  a  group 
effort. 

5 .  If  the  Model  was  not  Developed  In-house.  Who  Developed 

It? 

There  were  seven  models,  or  18. 918  percent,  developed 
outside  of  the  field  contracting  activity.  Of  the  seven 
models  developed  outside  of  the  field  contracting  activity, 
four,  or  10. 820  percent,  of  the  models  were  developed  for  the 
contracting  activity  by  the  contractor.  Of  the  seven  models 
developed  outside  of  the  field  contracting  activity,  two,  or 


1630/37  =  .8108 
1717/30  =  .5667 
1813/30  =  .4333 
,b7/37  =  .1892 
204/37  =  .1081 
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5 . 4 21  percent,  were  developed  by  the  Defense  Contract 
Administration  Services  Region  (DCASR)  headquarters.  Only  one 
contracting  activity,  or  2.7“  percent,  had  their  model 
developed  by  an  independent  software  developer. 


TABLE  3 

MODEL  DEVELOPMENT 


Developer  Number 

In-house  30 

Total  Outside  7 

Contractor  4 

DCASR  2 

Independent  1 


Percent 

81.1 

18.9 

10.8 

5.4 

2.7 


6 .  Does  Your  Activity  Use  the  Pricing  Model  in  Developing 
Price  Proposals  and  Purina  Price  Negotiations  Both? 

Of  the  37  field  contracting  activities  that  are 

currently  using  contract  pricing  models,  29,  or  78. 4s3  percent, 

of  the  activities  are  using  the  models  for  both  price 

proposals  and  price  negotiations. 

7 .  If  So.  is  the  Model  Currently  Used  bv  Your  Activity 
Adeuuate  for  All  Your  Activity's  Price  Proposal  and 
Price  Negotiation  Needs?  If  Not.  Whv  Not? 

Out  of  the  29  activities  that  use  their  contract 

pricing  models  for  both  price  proposals  and  price 

212/37  =  .0541 
“1/37  =  .0270 
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negotiations,  18,  or  62. 124  percent,  believe  that  their  models 
are  adequate  for  their  needs.  The  portion  of  activities  that 
have  models  and  feel  they  are  adequate  for  their  needs  is 
48. 6s5  percent. 

However,  11,  or  37. 9*  percent,  of  the  29  activities 
that  use  their  models  for  both  price  proposals  and  price 
negotiations,  feel  that  their  models  are  inadequate.  Since 
eight  activities  do  not  use  their  models  for  both  price 
proposals  and  price  negotiations,  it  is  assumed  that  these 
activities  deem  their  models  inadequate  for  both  purposes. 
Therefore,  1927,  or  51. 428  percent,  of  the  activities  with 
contract  pricing  models  feel  that  these  models  are  inadequate 
for  their  needs. 

The  following  are  typical  responses  as  to  why  11  out 

of  29  activities  that  use  their  models  for  both  price 

proposals  and  price  negotiations  responded  negatively: 

A  single  model  does  not  exist.  Contractor  proposals  vary 
and  each  spreadsheet  is  unique  to  one  proposal.  Certain 
generic  models  exist  for  some  divisions,  but  they  must  be 
edited  for  each  application. 

We  have  different  variations  depending  on  the  contract  type 
and  whether  things  like  escalation,  averaging  cost  of 
facilities  capital,  interest  rates  of  varying  periods  of 
performance,  etc.  are  involved. 


s<18/29  =  .6207 
29 18/37  =  .4864 
26ll/29  =  .3793 
2711  +  8  =  19 
2819/37  =  .5135 
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The  models  are  for  specific  contractors  because  of 
differences  in  pricing  methods.  (For  example) ,  bases  for 
various  burdens  are  different,  labor  categories  are 
different,  labor  rates  may  be  (yard-wide)  or  specific  to  a 
labor  category,  pricing  must  be  (de-escalated)  to  different 
bases,  etc. 

The  pricing  model  developed  is  for  two  of  our  contractors. 
Different  pricing  models  have  to  be  developed  to  correspond 
with  various  types  of  proposals  submitted  by  other 
contractors . 

(The  model  is)  adequate  for  probably  99  (percent)  of  our 
cases.  Occasionally,  some  strange  or  rarely  occurring  work 
task  will  include  an  unusual  cost  element  not  provided  for. 
(The)  model  is  still  easily  adaptable. 

(Our  activity  has)  inadequate  hardware,  inadequate  software, 
and  inadequate  training.  And,  many  contractors  (have) 
various  accounting  systems. 

Each  contractor  is  different.  That  is(,)  any  one  particular 
(contractor)  does  not  have  the  same  cost  elements  included 
in  (his)  proposals.  However,  with  modifications (, )  cost 
models  can  be  altered  to  fit  (different)  situations. 

The  model  is  adequate,  but  because  it  is  in  (LOTUS  1-2-3), 
(the  model)  is  not  on  all  PC's  (because)  some  (PC's)  do  not 
have  (LOTUS  1-2-3) . 

I  think  everyone  should  be  aware  that  it  is  very  obvious 
(and)  clearly  unrealistic( , )  or  unfeasible( , )  to  develop  one 
standard  pricing  model (, )  or  format(,)  for  the  universe. 
There  are  all  kinds  of  contractors  who  bid/propose  in 
totally  different  manners/ways  and  the  (price  analyst)  has 
to  prepare  his  report  to  be  consistent  with  the  way  the 
contractor  has  proposed  his  price  submission.  We  will  come 
closer  to  using  a  model  developed  for  each  individual 
contractor,  (rather)  than  trying  to  develop  one  standard 
pricing  model  for  the  world.  Every  pricing  office  will  set 
up  standard  formats/raodels/approaches  for  preparing  pricing 
reports  whenever  possible  for  efficiency  and  so  that  the 
(price  analyst)  (does  not)  re-invent  the  wheel  every  day. 

The  models  used  apply  specifically  to  two  contractors.  (The 
models  are)  not  applicable  to  price  proposals  received 
infrequently  from  a  variety  of  other  contractors. 
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8 .  If  Your  Activity  is  not  Using  the  Pricing  Model  for 
Both  Price  Proposals  and  Negotiations,  is  Your 
Activity  Using  the  Pricing  Model  Only  to  Prepare  Price 
Proposals? 

Of  the  eight  field  contracting  activities  not  using 
their  pricing  models  for  both  price  proposals  and 
negotiations,  five  activities,  or  13.5*  percent,  are  using 
them  exclusively  for  price  proposals  only. 

9 .  If  So.  When  Your  Negotiators  Receive  a  Counter¬ 
proposal  Purina  Negotiations.  Do  Your  Negotiators 
Manually  Calculate  Their  Positions?  If  Not.  How  Do 
They  Calculate  Their  Position  Then? 

Of  the  five  field  contracting  activities  that  use 
their  models  only  for  price  proposals,  three  activities,  or 
8.130  percent,  manually  calculate  their  positions  during 
negotiations. 

Of  the  five  field  contracting  activities  that  use 
their  models  only  for  price  proposals,  one  activity,  or  2.731 
percent,  calculates  its  position  by  some  other  means  during 
negotiations.  The  following  is  a  statement  from  that 
activity: 

Our  negotiators  (use  various  methods) .  (Some)  calculate 
(their)  positions  manually,  (some)  have  the  price  analyst 
recalculate  a  position  using  the  pricing  model,  (and  others) 
recalculate  (their  position)  using  a  separate  model  which 
they  have  developed  on  their  own. 


*5/37  =  .1351 
*3/37  =  .0811 
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Of  the  five  field  contracting  activities  using  models 

only  for  price  proposals,  one  activity,  or  2.7“  percent,  does 

not  conduct  negotiations,  therefore  the  question  does  not 

apply.  The  following  is  a  statement  from  that  activity: 

Negotiations  are  not  done  here.  We  send  a  floppy  of  our 
model  to  the  negotiator  with  each  proposal. 

10.  If  Your  Activity  is  Not  Using  the  Pricing  Model  Just 
for  Price  Proposals,  are  You  Using  Your  Pricing  Model 
Just  for  Negotiations?  If  So.  How  are  Your  Price 
Proposals  Developed? 

Of  the  eight  field  contracting  activities  not  using 
their  pricing  models  for  both  price  proposals  and  negotiat¬ 
ions,  three  activities,  or  8 . 133  percent,  are  using  their 
models  for  price  negotiations  only. 

All  three  of  the  activities  that  use  their  models  only 
for  price  negotiations  develop  their  price  proposals  using 
computerized  spreadsheets.  The  portion  of  activities  with 
models  that  develop  their  price  proposals  using  computerized 
spreadsheets  is  8.134  percent. 

11 .  Does  Your  Activity  Use  the  Pricing  Model  for  Anv  Other 
Applications  Besides  Proposals  and  Price  Negotiations? 
If  So.  What? 

Out  of  the  37  field  contracting  activities  that  have 
contract  pricing  models,  34,  or  91. 9s5  percent,  do  not  use 


“1/37  *  .0270 
“3/37  =  .0811 
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their  models  for  any  purpose  other  than  price  proposals  and 
price  negotiations. 

However,  three  of  the  37  activities,  or  8.1*  percent, 
said  that  they  did  have  other  applications  for  their  models. 

The  following  are  statements  from  the  three  activities 

that  have  applications  for  their  models  besides  price 

proposals  and  price  negotiations: 

Our  pricing  programs  incorporate  the  business  clearance. 

In  addition  to  price  proposals  and  price  negotiations,  the 
model  is  used  for  making  estimate(s)  to  (completion). 

(In  addition  to  price  proposals  and  price  negotiations,  the 
model  is  used  for)  field  pricing  reports. 

12 .  If  Your  Activity  Does  not  Currently  Have  a 

Computerized  Pricing  Model.  Have  They  Ever  Used  One 

Before?  If  Not.  Whv  Not? 

Of  the  37  field  contracting  activities  that  do  not 
currently  have  a  computerized  pricing  model,  35,  or  94. 637 
percent,  have  never  used  one  before. 

The  most  typical  answer  given  by  these  35  activities 
was,  "(A  computerized  pricing  model  was)  not  available." 

The  following  are  other  statements  that  some  of  the 
activities  made: 

(This  activity  is)  almost  exclusively  involved  with 
competitive  and/or  commercial  type  items. 

We  do  not  consider  that  a  pricing  model  is  adaptable  to  the 
many  pricing  scenarios  utilized  by  prospective  contractors. 


*3/37  =  .0811 
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(This  activity  is)  not  aware  of  (a  pricing  model  ever  being 
used) ,  and  (we)  have  not  needed  (a  pricing  model)  before. 

We  have  not  used  one,  but  (we)  have  reviewed  and  commented 
on  several  (that  were)  provided  by  our  regional  office. 
None  were  appropriate  or  had  wide  application. 

As  a  small  purchase  activity,  there  is  no  need  for  such  a 
model,  as  price  breakdowns  are  not  usually  required. 

Spreadsheets  are  used  exclusively. 

(This  activity  has)  low  volume.  (There  have)  only  (been) 
three  significant  negotiations  over  (a)  three  year  period. 

This  activity  has  achieve (d)  very  high  rates  of  competition 
and  extensive  cost  analysis  or  price  analysis  is  normally 
not  required.  Price  reasonableness  is  determined  based  on 
competition. 

(This  is)  a  small  base  buying  activity  heavily  oriented 
toward  small  purchase.  (We  are)  unaware  that  such  models 
exist. 

This  activity  is  cognizant  of  two  separate  divisions,  with 
different  cost  structures  within  the  organization.  Also, 
variation (s)  in  applicable  cost  elements  for  different  types 
of  proposals  and  different  weapons  systems  programs  (have) 
made  a  standardized  model  (impractical) . 

(This  activity  has)  little  need  and  no  knowledge  of  any 
model.  Base  contracting  is  (Invitation  for  Bid),  (providing 
the)  low  bid(der)  (with  the)  award.  (This  activity 
performs)  little  negotiation. 

The  opportunity  has  not  presented  itself. 

Models  do  not  work  (due  to  the)  different  logic  (involved, 
because)  proposals  (are)  always  different. 

(There  is)  too  much  judgement  and  fact  sensitivity  to 
justify  such  an  item. 

It  is  very  difficult,  if  not  impossible  to  develop  a 
single/multiple  model  for  all  cases. 

(A  pricing  model)  is  not  considered  to  be  a  worthwhile  tool. 
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13 .  If  So,  Which  Computerized  Pricing  Model  did  They  Use? 

Whv  Did  They  Stop  Using  it? 

Only  two  out  of  37,  or  5.4s®  percent,  of  the  field 
contracting  activities  that  currently  do  not  have  a 
computerized  contract  pricing  model,  have  ever  used  one 
before. 


The  following  are  statements  given  by  those  two 
activities: 

(This  activity  used  a)  locally  developed  model  written  in 
BASIC.  Models  are  too  confining.  Every  proposal  has  to  be 
the  same.  They  save  time,  but  stifle  creativity. 

(This  activity  used  a)  tailor  made  (model)  established  by 
(a)  cost  monitor  and  (a)  price  analyst.  (The  activity) 
stopped  (using  the  model)  when  (the  contractor)  split  (and 
was)  bought  by  (two  different  corporations)  .  (There  are) 
two  new  systems  (that  have)  not  (been)  finalized/approved 
yet. 


14 .  If  Your  Activity  Does  not  Have  a  Computerized  Pricing 
Model.  Does  Your  Activity  Use  a  Computerized 
Spreadsheet? 

All  37  of  the  field  contracting  activities  that  do  not 
currently  have  a  computerized  pricing  model ,  use  a 
computerized  spreadsheet. 

15 •  If  Not.  How  Does  Your  Activity  Prepare  Price  Proposals 
and  How  do  Your  Negotiators  Calculate  Their  Positions 
During  Negotiations? 

All  37  of  the  field  contracting  activities  that  do  not 
currently  have  a  computerized  pricing  model  use  a  computerized 
spreadsheet,  therefore  this  question  does  not  apply. 


m2/37  =  .0541 
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16.  If  Your  Activity  Does  Use  a  Computerized  Spreadsheet. 

What  Software  is  Your  Activity  Using? 

The  37  activities  that  use  computerized  spreadsheets 
use  a  variety  of  software.  The  majority  of  the  activities  are 
using  LOTUS  1-2-3.  Specifically,  11  out  of  37,  or  29.7s9 
percent,  use  LOTUS  1-2-3  version  2.01  or  better.  LOTUS  1-2-3 
is  followed  closely  by  Enable.  Out  of  37  activities  that  use 
computerized  spreadsheets,  ten,  or  2740  percent,  use  Enable. 
Out  of  37  activities  that  use  computerized  spreadsheets, 
seven,  or  18. 941  percent,  use  both  LOTUS  1-2-3  and  Enable  to 
run  their  spreadsheets.  Of  the  Marine  Corps  activities,  four, 
or  10. 842  percent,  use  Wang's  20/20.  Out  of  37  activities  that 
use  computerized  spreadsheets,  two,  or  5.443  percent,  use 
Symphony  (a  LOTUS  product).  Only  three  out  of  37,  or  8.144 
percent,  use  some  other  type  of  software  to  run  their 
spreadsheets. 
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TABLE  4 


SOFTWARE  CURRENTLY  RUNNING  COMPUTERIZED  SPREADSHEETS 


Software 

Number 

Percent 

LOTUS  1-2-3 

11 

29.7 

Enable 

10 

27.0 

Both  LOTUS  &  Enable 

7 

18.9 

Wang  20/20 

4 

10.8 

Symphony 

2 

5.4 

Other  Software 

3 

8.1 

17 .  Does  Your  Activity  Use  the  Computerized  Spreadsheet  in 
Developing  Price  Proposals  and  During  Negotiations 
Both? 

Out  of  37  activities  that  use  computerized  spread¬ 
sheets,  26,  or  70. 3*  percent,  use  them  for  developing  price 
proposals  and  during  negotiations  both. 

On  the  other  hand,  11  out  of  37,  or  29. 7*®  percent,  of 
the  activities  do  not  use  computerized  spreadsheets  for  both 
price  proposals  and  negotiations. 

18 .  If  Your  Activity  is  Not  Using  its  Computerized 
Spreadsheet  for  Both  Price  Proposals  and  Negotiations, 
is  Your  Activity  Using  the  Spreadsheet  Only  to  Prepare 
Price  Proposals? 

Of  the  11  activities  not  using  their  computerized 
spreadsheets  for  both  price  proposals  and  negotiations,  six 


*26/37  =  .7027 
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activities,  or  16. 247  percent,  use  their  spreadsheets  to 
prepare  price  proposals  only. 

19 .  If  So.  When  Your  Negotiators  Receive  a  Counter¬ 
proposal  Purina  Negotiations,  do  Your  Negotiators 
Manually  Calculate  Their  Positions?  If  Not.  How  do 
They  Calculate  Their  Position  Then? 

Of  the  six  field  activities  out  of  37  using  their 
spreadsheets  for  price  proposals  only,  all  six,  or  16. 2““ 
percent,  calculate  their  positions  manually  during 
negotiations . 

20 .  If  Your  Activity  is  Not  Using  the  Computerized 
Spreadsheet  Just  for  Price  Proposals,  are  You  Using 
Your  Spreadsheet  Just  for  Negotiations?  If  So.  How 
are  Your  Price  Proposals  Developed? 

None  of  the  37  activities  that  are  using  computerized 
spreadsheets  use  them  for  price  negotiations  only. 

21.  Does  Your  Activity  Use  the  Spreadsheet  for  Anv  Other 
Applications  Besides  Price  Proposals  and  Price 
Negotiations?  If  So.  What? 

Of  the  37  field  contracting  activities  that  use 
computerized  spreadsheets,  five,  or  13. 549  percent,  use  them 
for  other  applications  besides  price  proposals  and  price 
negotiations . 

The  following  are  statements  given  by  these  five 
activities: 

(Aside  from  price  proposals  or  negotiations,  this  activity 
uses  spreadsheets  for)  abstracts  for  bids,  computations  for 
DD1057 ,  (and)  statistics  on  procurement  data. 


476/37  =  .  1622 
48 6/37  =  .  1622 
49 5/ 31  =  .  1351 
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(Aside  from  price  proposals  or  negotiations,  this  activity 
uses  spreadsheets  for)  budget  formulation  and  control,  and 
management  data  control  functions. 

(This  activity  uses)  (Automation  of  Procurement  and 
Accounting  Data  Entry) (system) ,  (for)  automated  (Naval 
Supply)  purchasing. 

(Aside  from  price  proposals  or  negotiations,  this  activity 
uses  spreadsheets  for)  both  number  crunching  and  data-base 
management . 

(Aside  from  price  proposals  or  negotiations,  this  activity 
uses  spreadsheets  for)  departmental  budgeting  and  reports. 

22 .  Is  the  Computerized  Spreadsheet  Currently  Used  by  Your 
Activity  Adequate  for  All  Your  Activity's  Price 
Proposal  and  Price  Negotiation  Needs?  If  Not.  Whv 
Not? 

Of  the  37  field  contracting  activities  that  use 

computerized  spreadsheets,  34,  or  91.9s0  percent,  find  them 

adequate  for  their  needs.  Only  three,  or  8.151  percent,  of  the 

activities  feel  that  their  spreadsheets  are  inadequate. 

The  following  are  statements  from  two  of  the 

activities  that  feel  their  spreadsheets  are  inadequate: 

(This  activity)  would  like  to  use  a  pricing  model  that  would 
be  general  in  scope,  so  that  it  would  be  useable  in  all 
pricing  situations. 

All  proposals  have  to  be  changed.  (There  is)  no  (single) 
format  because  of  years,  rates,  etc.  No  two  companys' 
proposals  (are  the)  same. 


so34/37  =  .9189 
91 3/ 3  7  =  .0811 
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23 .  Would  Your  Activity  be  Interested  in  a  Standard 

Pricing  Model?  If  Not.  Whv  Not? 

Of  the  74  field  contracting  activities  surveyed,  39, 
or  52.7“  percent,  said  that  they  would  be  interested  in  a 
standard  pricing  model.  Virtually  all  of  those  39  stipulated 
a  caveat  that  the  model  must  be  flexible  enough  to  accommodate 
various  cost  accounting  systems  and  many  different  contractor 
proposal  formats. 

Of  the  39  activities  that  responded  "yes"  to  a 
standard  pricing  model,  19,  or  48.7s3  percent,  are  activities 
that  are  currently  using  models  and  20,  or  51.3s4  percent,  are 
activities  that  are  currently  using  spreadsheets. 

On  the  other  hand,  35  activities,  or  47.3s*  percent, 
said  that  they  were  not  interested  in  a  standard  pricing 
model . 

Of  the  35  activities  that  responded  "no"  to  a  standard 
pricing  model,  18,  or  51.4s®  percent,  are  activities  that  are 
currently  using  models  and  17,  or  48.6s7  percent,  are 
activities  that  are  currently  using  spreadsheets. 


“39/74  =  .5270 
“19/39  =  .4872 
*"20/39  =  .5128 
**35/74  =  .4730 
*®18/3  5  =  .5143 
S717/35  =  .4857 
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TABLE  5 


INTEREST  IN  A  STANDARD  PRICING  MODEL 


Interested? 

Number 

Percent 

Yes 

39 

52.7 

Yes  (Models) 

19 

48.7 

Yes  (Spreadsheets) 

20 

51.3 

No 

35 

47.3 

No  (Models) 

18 

51.4 

No  (Spreadsheets) 

17 

48.6 

The  following  are  statements  from  those  activities 

that  responded  "no"  to  a  standard  pricing  model: 

We  have  already  customized  our  model  to  adapt  to  the  various 
accounting  systems  for  each  of  the  contractors  we  review. 

Our  pricing  model  must  be  compatible  with  (the  contractor's) 
proposal  and  accounting  system. 

Our  primary  model,  the  cost  summary  spreadsheet,  is 
individually  tailored  to  virtually  each  contractor  under  our 
cognizance.  This  is  necessary  since  pricing  proposals  are 
usually  structured  differently  by  each  offeror.  (In  other 
words , )  the  particular  cost  elements  vary  somewhat  by 
contractor. 

Generic  (models)  are  too  big,  too  little,  etc.  Personali¬ 
zation  is  a  must  for  ease  of  use. 

Each  proposal  is  different.  Some  proposals  are  line  item  by 
year,  some  by  (work  breakdown  structure) ,  etc.  Each  (model) 
has  to  be  prepared  to  be  consistent  with  the  proposal  and 
the  way  the  particular  (contracting  officer)  wants  the 
recommendations  developed.  It  is  not  logical  to  try  to  have 
one  model  for  the  universe.  Each  pricing  office  would  never 
want  to  get  into  a  situation  where  they  were  expected  to 
submit  every  pricing  report  in  a  particular  format  when 
different  situations  or  approaches  might  warrant/dictate 
another  approach. 

Each  individual  model  is  unique  to  that  contractor. 

Our  models  are  (contractor)  division  and  program  specific. 
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Generally,  our  activity  is  too  diverse.  One  model  is 
usually  too  generic  to  address  the  varying  pricing 
structures  received. 

Considering  the  dozens  of  contractors  handled,  each  with  its 
own  pricing  methodology,  I  question  whether  a  standard  model 
could  be  used. 

(This  activity  is  not  interested  in  a  standard  pricing 
model,)  unless  the  model  can  be  adapted  to  different 
shipbuilders  and  methods  of  pricing. 

Our  rate  structure  (is)  somewhat  different  than  other 
activities. 

Standard  pricing  models  are  designed  for  a  particular 
contractor (, )  not  (for)  all  (contractors).  Each  contractor 
is  different. 

We  believe  (our  model)  to  be  far  more  comprehensive  and 
utilitarian  than  any  other  (model)  yet  developed. 

All  contractors  have  unique  accounting  systems.  Each 
pricing  model  is  specially  tailored  for  the  particular 
contractor's  books,  records,  and  (accounting)  system. 

(We)  (do  not)  think  (a  standard  pricing  model)  would 
accommodate  the  unique  accounting  systems  of  each 
contractor,  or  division,  without  a  lot  of  editing. 

(A  standard  pricing  model)  probably  would  not  be  compatible 
with  (each)  contractor's  pricing  format. 

We  do  not  consider  that  a  pricing  model  is  adaptable  to  the 
many  pricing  scenarios  utilized  by  prospective  contractors. 

We  have  many  contractors  submitting  proposals.  Each 
(proposal)  is  unique.  A  model  does  not  recognize  this  level 
of  diversity. 

(A  standard  pricing  model)  cannot  be  easily  used  for  (the) 
variety  of  proposals  (we  receive) .  We  need  to  relate  to 
contractors  submission,  so  (our)  negotiators  are  on  (the 
same)  level. 

(We  are)  unable  to  use  (a)  standard  (pricing  model)  for  just 
the  two  contractors  here,  due  to  differences  in  (their) 
estimating  systems. 

Each  proposal  stands  on  its  own.  Requests  for  data 
presentation  vary  by  customer.  Models  are  too  confining 
(because)  every  proposal  has  to  be  the  same. 
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(This)  activity  is  (too)  varied.  (An)  all  encompassing 
model  would  be  cumbersome. 

Small  purchase  is  meant  to  be  a  streamlined  method  of 
procurement  without  a  requirement  for  detailed  price 
analysis  such  as  a  pricing  model  or  computerized  spreadsheet 
would  provide. 

Each  requirement  is  unique  and  the  variation  among  the 
different  requirements  make(s)  the  computerized  spreadsheet 
the  best  tool  available. 

There  is  no  way  to  create  a  generic  model  which  would  fit 
all  contractors  and  all  pricing  actions,  and  (still)  be 
useful . 

We  deal  with  numerous  contractors,  all  of  whom  propose  in 
their  own  unique  method.  Standardized  models  are  not  very 
relevant  to  our  situation. 

With  the  low  volume  of  proposals  and  different  (accounting) 
systems  used  by  the  various  contractors,  we  develop  a 
computer  spreadsheet  for  each  effort. 

It  seems  unlikely  that  a  standard  model  could  accommodate 
the  wide  variety  of  contractor  accounting  systems  that 
produce  cost  proposals. 

A  standard  pricing  model  is  not  practical  due  to  the  (fact 
that)  types  and  formats  of  proposals  are  different,  cost 
elements  are  different  for  each  contract,  and  each 
contractor's  cost  accounting  structure  is  different.  A 
standard  model  would  be  too  complex  to  develop.  Maybe  a 
standard  model  at  the  corporate,  or  division,  level,  but  not 
Navy  or  Department  of  Defense  wide. 

The  biggest  problems  are  the  differences  in  accounting 
systems  and  proposal  formats  for  each  contractor.  A 
standard  model  is  not  practical. 

Our  contractor  has  two  divisions.  One  division  has  23  cost 
categories,  the  other  has  17  or  18.  Each  cost  has  a 
different  name.  (A  standard  pricing  model)  is  just  not 
practical . 

(A  standard  pricing  model  is)  not  practical.  (There  are) 
different  accounting  systems,  overheads  are  different,  and 
cost  elements  are  different. 

If  you  want  to  standardize  a  (pricing)  model,  then  you  must 
get  the  contractors  to  standardize  their  proposal  formats. 
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One  standard  model  is  infeasible  due  to  contractor  unique 
items.  Maybe  three  standard  models  would  be  better.  A 
basic,  medium,  and  complex  model. 

G.  STATISTICAL  INFERENCES 

The  purpose  of  this  section  is  to  extract  and  deduce 
reasonable  inferences  from  the  survey  data.  This  section 
addresses  five  inferences  that  were  deduced  from  the  data. 
They  are  as  follows: 

-  A  collective  opinion  exists; 

There  is  a  preferred  software; 

There  is  a  necessity  for  computerized  automation  in 
developing  price  proposals  and  for  use  during  price 
negotiations ; 

The  expertise  exists  to  develop  computerized  contract 
pricing  models  in-house; 

-  There  is  not  a  desire  or  a  need  for  a  single  agency/ 
service-wide  standard  model  at  this  time. 

1.  Collective  Opinion 

The  sample  size  of  74,  with  a  combined  response  rate 
of  54  percent,  represents  a  little  over  half  of  all  major  DLA, 
Navy  and  Marine  Corps  field  contracting  activities,  even 
though  about  half  of  the  sample  is  represented  by  DLA 
activities.  The  individual  response  rates  of  50.7  percent, 
54.9  percent,  and  72.7  percent,  for  DLA,  Navy,  and  Marine 
Corps  respectively,  suggest  that  the  inferences  do  reflect  the 
collective  opinions  of  the  activities. 
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2 .  Preferred  Software 


The  total  percent  of  activities  that  use  LOTUS  1-2-3 
to  run  their  models  and  spreadsheets  is  40. 5s®  percent.  The 
total  percent  of  activities  that  use  Enable  to  run  their 
models  and  spreadsheets  is  21.6s®  percent.  The  total  percent 
of  activities  that  use  both  LOTUS  1-2-3  and  Enable  to  run 
their  models  and  spreadsheets  is  16. 290  percent.  The  total 
percent  of  activities  that  use  Symphony  (a  LOTUS  product)  to 
run  their  models  and  spreadsheets  is  8.181  percent.  The  total 
percent  of  activities  that  use  Wang's  20/20  is  5.4®  percent. 
And,  the  total  percent  of  activities  that  use  other  software 
to  run  their  models  and  spreadsheets  is  8.163  percent.  The 
collective  percentage  that  use  LOTUS  1-2-3,  or  a  LOTUS 
compatible  product,  is  64.9“  percent.  Therefore,  it  appears 
that  LOTUS  1-2-3  is  the  preferred  software  in  major  field 
contracting  activities. 


“(19  +  ll)/74  =  .4054 

“(6  +  10)/74  =  .2162 

“(5  +  7)/74  =  .1622 

81  (4  +  2)/74  =  .0811 

®4/74  =  .0541 

83  ( 3  +  3)/74  =  .0811 

“(30  +  12  +  6)/74  =  .6486 


96 


TABLE  6 


PREFERRED  SOFTWARE 


Software 

Number 

Percent 

LOTUS  1-2-3 

30 

40.5 

Enable 

16 

21.6 

Both  LOTUS  &  Enable 

12 

16.2 

Symphony 

6 

8.1 

Wang  20/20 

4 

5.4 

Other  Software 

6 

8.1 

LOTUS  Products 

48 

64.9 

3 •  Necessity  of  Computerized  Automation  for  Developing 
Price  Proposals  and  for  Use  During  Price  Negotiations 

The  total  percent  of  activities  that  use  their  models 
or  spreadsheets  for  both  price  proposals  and  price  negotia¬ 
tions  is  74.3s5  percent.  The  total  percent  of  activities  that 
use  their  models  or  spreadsheets  for  just  price  proposals  is 
14. 9s6  percent.  The  total  percent  of  activities  that  use  their 
models  or  spreadsheets  for  just  price  negotiations  is  4.167 
percent.  Only  nine,  or  12. 2s8  percent,  of  the  total  activities 
manually  calculate  their  negotiation  positions.  And,  zero 
activities  manually  develop  their  price  proposals.  Therefore, 
it  seems  that  computerized  automation  is  necessary  for  field 


“(29  +  26)/74  =  .7432 
“(5  +  6)/74  =  .1486 
873/74  =  .0405 
88  ( 3  +  6)/74  =  .  1216 
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contracting  activities  to  develop  price  proposals  and  to  use 
during  price  negotiations. 


TABLE  7 

NECESSITY  OF  COMPUTERIZED  AUTOMATION 

Method  Number  Percent 


Models/Spreadsheets  for  Proposals/ 

Negotiations  55  74.3 

Models/Spreadsheets  for  Proposals  Only  11  14.9 

Models/Spreadsheets  for  Negotiations  Only  3  4.1 

Manually  Calculate  Negotiation  Position  9  12.2 

Manually  Develop  Price  Proposal  0  0.0 


4 .  Expertise  to  Develop  a  Model  In-house 

The  percent  of  activities  with  models  that  developed 
them  in-house  is  81.1.  All  30  models  developed  in-house  were 
developed  by  cost/price  analysts  or  someone  from  the  financial 
services  branch  of  the  activity.  Of  the  18.9  percent  of  the 
activities  that  had  their  models  developed  outside  the 
activity,  10.8  percent  were  developed  by  contractors  and  5.4 
percent  were  developed  for  the  activities  by  the  DCASR .  This 
means  that  the  expertise  may  exist  within  this  16.2®  percent, 
however  the  expertise  was  not  used.  Only  one  activity  with  a 
model  used  a  software  developer  to  produce  the  model.  Of  the 
activities  that  currently  do  not  use  a  pricing  model,  many 
said  that  they  never  used  one  because  one  was  not  available. 

®10 . 8  +  5.4  =  16.2 
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However,  none  of  the  activities  that  use  spreadsheets 
indicated  that  they  did  not  use  a  model  because  they  did  not 
have  the  expertise  to  develop  one.  Therefore,  it  can 
reasonably  be  assumed  that  the  expertise  to  develop  a  model 
exists  in-house  at  almost  all  field  contracting  activities. 

5.  Desire  or  Need  for  a  Standardized  Model 

Half  of  the  activities  have  models  and  18,  or  48.6 
percent,  feel  that  their  models  are  adequate  for  their  needs. 
The  other  half  of  the  activities  use  computerized  spread¬ 
sheets  and  34,  or  91.9  percent,  feel  that  their  spreadsheets 
are  adequate  for  their  needs.  The  total  percent  of  activities 
that  feel  their  models  or  spreadsheets  are  adequate  is  70. 370 
percent.  Of  the  29  activities  that  use  their  models  for  both 
price  proposals  and  price  negotiations,  11  feel  that  their 
models  are  inadequate.  Since  eight  activities  do  not  use 
their  models  for  both  price  proposals  and  price  negotiations, 
it  is  assumed  that  these  activities  deem  their  models 
inadequate  for  both  purposes.  Therefore,  19,  or  51.4  percent, 
of  the  activities  with  contract  pricing  models  feel  that  these 
models  are  inadequate  for  their  needs.  Only  three,  or  8.1 
percent,  of  the  activities  feel  that  their  spreadsheets  are 
inadequate.  The  total  percent  of  activities  that  feel  their 
models  or  spreadsheets  are  inadequate  is  29. 771.  Only  two  of 
the  activities  that  do  not  currently  use  models  have  ever 

70  ( 18  +  34)/74  =  .7027 

71  ( 19  +  3)/74  =  .2974 
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tried  one  before.  Additionally,  only  a  little  over  half  of 
the  activities,  52.7  percent,  are  interested  in  a  standard 
model.  Of  this  half,  the  activities  are  virtually  evenly 
divided  between  activities  with  models  and  those  with 
spreadsheets,  19  and  20  respectively.  No  group,  particularly 
those  with  spreadsheets,  51.3  percent,  is  heavily  in  favor  of 
a  standard  model.  Furthermore,  a  great  deal  of  activities 
doubt  the  feasibility  of  developing  such  a  model  and  even  more 
activities  question  the  practicality  of  such  a  model.  There¬ 
fore,  it  is  perceived  that  there  is  not  a  desire,  nor  a  r.eed, 
to  develop  a  single  agency/service-wide  standard  model  at  this 
time. 


TABLE  8 

DESIRE  OR  NEED  FOR  A  STANDARD  MODEL 


Desire/Need 

Number 

Percent 

Activities  with  Models 

37 

50.0 

Models  Adequate 

18 

48.6 

Models  Inadequate 

19 

51.4 

Activities  with  Spreadsheets 

37 

50.0 

Spreadsheets  Adequate 

34 

91.9 

Spreadsheets  Inadequate 

3 

8.1 

Total  Adequate 

52 

70.3 

Total  Inadequate 

22 

29.7 

Interested  in  a  Standard  Model 

39 

52.7 
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H.  PRACTICABILITY  ANALYSIS 


The  focus  of  this  study  is  the  practicability  of 
developing  a  standard,  stand-alone,  contract  pricing  model  of 
an  "intelligent"  computerized  decision  support  system  designed 
to  aid  in  price  calculation.  An  "intelligent"  system  is  an 
interactive  computer  system  that  does  not  have  problem-solving 
capabilities,  but  is  intended  to  guide  the  user  to  performing 
at  an  expert  level. 

The  proposed  model  was  designed  to  calculate  price 
positions  relative  to  the  Government,  the  contractor,  and  the 
current  negotiated  position.  The  main  objective  was  to 
construct  a  system  that  could  be  used  by  an  unskilled, 
inexperienced  analyst/negotiator  to  make  complex  calculations, 
thereby  greatly  assisting  in  the  procurement  process,  as  well 
as  potentially  saving  the  Government  large  amounts  of  time  and 
money. 

The  various  cost  models  have  shown  a  savings  from  8:1  to 
10:1  in  terms  of  man-hours  consumed  in  pricing  computations 
and  report  operations,  while  being  very  useful  in  all 
aspects  of  the  pricing  process.  [Ref.  7:p.  4] 

The  analyst/negotiator,  using  the  proposed  model,  could 
audit  the  contractor's  price  proposal,  compute  a  negotiation 
objective  based  on  the  results  of  his  analysis,  recompute  a 
position  during  negotiations  and  present  cost/price  data  in 
formatted  hard-copy  spreadsheets. 

However,  several  issues  arose  surrounding  the 
practicability  of  developing  a  standard,  stand-alone, 
computerized  contract  pricing  model  for  the  Navy.  There  are 
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four  questions  concerning  these  issues  that  will  be  addressed. 
They  are: 

-  What  is  the  state  of  existing  technology? 

Is  developing  the  proposed  model  feasible? 

Is  developing  the  proposed  model  practical? 

What  is  the  current  environment? 

1 .  What  is  the  State  of  Existing  Technology? 

Advanced  technology  in  the  form  of  personal  computers 
already  exists  at  field  contracting  activities.  The  use  of 
some  or  all  of  this  technology  can  assist  field  contracting 
activities  improve  their  service  by  minimizing  procurement 
lead  times  and  maximizing  productivity. 

One  problem  related  to  advanced  technology  rests  with 
an  individual  organization's  ability  to  fully  understand  the 
available  information  technology,  assess  its  capabilities  and 
potential  applicability,  acquire  the  needed  software,  and 
implement  it  within  the  procurement  environment  that  already 
exists. 

There  is  an  increased  use  of  automated  techniques 
within  field  contracting  activities,  but  most  of  these 
techniques  are  "closed  systems."  In  other  words,  each  system 
deals  with  the  procurement  process  only  as  it  relates  to  a 
particular  field  contracting  activity.  In  addition,  many 
systems  in  production  use  today  are  using  conventional 
automated  data  processing  (ADP)  technologies,  many  with 
terminals  linked  to  large  mainframe  computers. 
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Acquiring  automation  capability  has  become  extremely 
complex.  Activities  are  not  buying  mainframe  computers  or  the 
associated  peripherals.  The  systems  today  are  multi- 
component,  consisting  of  personal  computers,  workstations,  and 
local  area  networks.  In  addition,  these  systems  perform  a 
vast  array  of  functions  and  are  driven  by  a  wide  variety  of 
software. 

In  the  past,  some  contracting  activities  have 
interacted  with  a  computer  system  through  the  use  of  a 
terminal  linked  to  a  mainframe  system.  System  failure  at  peak 
processing  periods  was  a  major  drawback  to  the  mainframe 
system. 

The  advent  of  personal  computers  has  provided  field 
contracting  activities  with  computing  power  that  is  available 
under  their  direct  control.  Software  packages  such  as  LOTUS 
1-2-3  are  valuable  assets  to  the  contracting  activity. 

The  major  drawback  with  personal  computers  is  that 
computer  systems  expertise  is  dispersed  in  varying  degrees 
among  field  contracting  activities.  The  result  is  that  some 
activities  have  more  technical  knowledge  and  are  able  to 
develop  a  better  system  that  applies  the  resident  technology 
to  its  full  potential.  Other  activities  must  be  content  with 
inferior  techniques  because  knowledge  is  not  widely 
disseminated. 

Every  field  contracting  activity  should  be  aware  of 
the  advantages  offered  by  new  technology,  they  ought  to 
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consider  developing  applications  that  utilize  the  technology 
to  its  full  potential,  and  they  should  disseminate  information 
throughout  the  entire  contracting  community. 

2 .  Is  Developing  the  Proposed  Model  Feasible? 

In  the  course  of  the  study,  the  question  of 
feasibility  came  up  several  times.  With  so  many  different 
types  of  proposals  submitted  in  different  formats,  and  with 
different  cost  elements  and  pools  under  varying  cost 
accounting  systems  structured  differently  from  organization  to 
organization,  or  even  within  organizations,  is  it  feasible  to 
develop  a  pricing  model  that  can  handle  all  these  variables? 

The  answer  is  a  qualified  yes.  The  Air  Force's  COPPER 
IMPACT  project  is  an  example  of  a  successful  model.  However, 
two  very  important  considerations  must  be  taken  into  account. 

First,  to  develop  the  proposed  model  in  a  programming 
language,  such  as  BASIC  or  FORTRAN,  would  be  like  developing 
a  software  package  with  capabilities  similar  to  LOTUS  1-2-3 
or  Enable. 

Second,  to  develop  the  proposed  model  using  a 
particular  brand  of  software  would  require  either  too  many 
complex  macros  to  cover  each  possible  situation,  or  leaving 
the  proposed  model  in  a  very  basic  form  not  much  different 
from  the  software  package  that  drives  it. 
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3 .  Is  Developing  the  Proposed  Model  Practical? 

The  major  concern  expressed  by  those  activities 
surveyed  was  flexibility.  Contracting  by  nature  must  be 
flexible. 

With  so  many  different  types  of  proposals  submitted  in 
different  formats,  and  with  different  cost  elements  and  pools 
under  varying  cost  accounting  systems  structured  differently 
from  organization  to  organization,  or  even  within 
organizations,  is  it  feasible  to  develop  a  pricing  model  that 
can  handle  all  these  variables?  The  answer  was  yes,  but  two 
important  considerations  were  raised  which  question  the 
practicality  of  the  proposed  model. 

First,  it  would  not  be  practical  for  the  Navy  to 
develop  a  model  that  is  essentially  a  spreadsheet  software 
package  when  many  similar,  sophisticated  software  packages  are 
currently  available  on  the  market  at  a  low  cost  and,  also, 
already  exist  in  field  contracting  activities. 

And  second,  the  proposed  model  would  either  be  too 
complex  and  cumbersome  or  so  basic  that  it  might  as  well  have 
been  left  in  the  original  form  of  the  software  package  that 
drives  it. 

Forced  standardization,  system  complexity  and 
cumbersome  procedures  will  offset  potential  productivity.  The 
ideal  system  should  be  responsive  and  user  friendly.  Thus, 
ergonomics  becomes  a  factor.  The  more  standardization, 
commands  and  procedures  associated  with  the  model,  the  less 
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flexible  and  user  friendly  it  becomes,  hence  the  less  likely 
it  will  be  received  favorably  by  price  analysts/negotiators. 

While  there  are  some  common  aspects  to  companys' 
respective  price  proposals,  cost  elements,  and  accounting 
systems,  there  are  also  many  variations  to  contend  with  that 
demand  flexibility  in  a  pricing  model.  Each  company  has  its 
own  cost  elements  with  cost  accumulation  pools  that  require 
different  calculations.  Additionally,  there  are  financial 
management,  cost  estimating,  and  rate  structure  peculiarities. 
Also,  some  companies  have  multiple  divisions  and  several 
locations,  each  with  its  own  accounting  system. 

One  contractor  interviewed  has  three  companies  that 
collectively  have  over  200  labor,  overhead,  general  and 
administrative,  and  facilities  capital  cost  of  money  pools 
used  to  accumulate  costs.  This  contractor  also  has  over  200 
bid  factors  (cost  estimating  relationships)  maintained  for  use 
on  cost  proposals. 

Rates  and  factors  are  so  dynamic  and  they  are 
constantly  being  updated  or  revised  to  accommodate 
reorganizations,  program  realignments  driven  by  budget 
considerations,  and  Total  Quality  Management  (TQM)  personnel 
realignment  initiatives. 

Consequently,  cost  elements  and  rate  agreements  remain 
elusive  due  to  what  can  be  described  as  normal  instability. 

For  these  reasons,  some  field  contracting  activities 
currently  have  more  than  one  model  to  deal  with  these 
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variations.  Some  activities  require  different  models  for 
different  contractors.  Sometimes,  field  contracting 
activities  require  different  models  for  the  same  contractor 
for  use  on  separate  contracts  or  because  the  contractor  has 
different  companies  or  divisions. 

Furthermore,  field  contracting  activities  prefer 
different  price  proposal  formats.  Many  activities  have 
formats  they  designed  and  are  comfortable  with,  while  others 
model  their  formats  after  their  contractor's  price  proposal 
format. 

If  price  proposal  formats  were  standardized  Navy-wide, 
it  would  be  extremely  difficult  to  get  the  defense  industry  to 
standardize  the  submission  of  their  price  proposals.  If  the 
defense  industry  were  forced  to  standardize  the  submission  of 
their  price  proposals,  the  Department  of  Defense  would  have  to 
standardize  the  other  agencys '/Services '  price  proposal 
formats  as  well.  This  is  a  very  unlikely  proposition. 

Currently,  some  field  contracting  activities  are 
simply  giving  the  contractors  floppy  disks  and  having  price 
proposals  submitted  by  the  contractors  on  floppy  disks  that 
include  a  workspace  for  the  Government  field  contracting 
activity  to  enter  its  objective  position  and  another  workspace 
for  use  during  negotiations. 

Therefore,  a  Navy-wide  standard,  stand-alone, 
computerized  contract  pricing  model  certainly  is  not  necessary 
and  does  not  appear  practical .  A  model  at  the  activity  or 
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organizational  level  has  merits, 
always  necessary. 


But  then,  a  model  is  not 


Small  purchase  activities  would  have  limited 
application  for  pricing  models  due  to  the  nature  of  small 
purchasing.  Awards  are  usually  made  competitively  without 
price  breakdowns,  extensive  analyses,  or  negotiations. 

Each  contracting  requirement  is  unique  and  the 
variation  among  the  different  requirements  makes  the 
computerized  spreadsheet  the  best  tool  available  to  small 
purchase  activities. 

4 .  What  is  the  Current  Environment? 

System  standardization  is  being  overlooked  because 
field  activities  can  independently  buy  low-cost,  powerful 
software  packages  that  meet  their  individual  needs. 

Concepts  such  as  networking,  portability, 
connectivity,  and  interoperability  are  important  concerns  for 
standardization.  For  these  reasons,  Navy-wide  software 
standardization  warrants  consideration. 

Currently,  during  times  of  reduced  resources,  cost  is 
another  concern.  Congressional  funding  cutbacks  are 
threatening  a  number  of  programs.  Faced  with  serious  budget 
constraints,  the  Navy  should  not  invest  a  substantial  sum  of 
money  into  the  development  of  the  proposed  model. 

Too  often,  ambitious  designs  and  grandiose  ideas 
evolve  into  a  system  that  is  comprised  of  too  many  "bells  and 
whistles."  By  utilizing  existing  software,  proven  technology 
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and  techniques,  the  cost  of  developing  such  a  model  can  be 
greatly  reduced  or  even  eliminated,  thus  preserving  valuable 
resources. 

Finally,  some  contracting  activities  have  not  pursued 
developing  a  standard  model  because  of  normal  workload 
requirements  and  the  fact  that  spreadsheets  have  been  the  most 
adaptable  application  of  suiting  their  needs. 

I.  SUMMARY 

This  chapter  analyzed  the  practicability  of  developing  the 
standard,  stand-alone,  computerized  contract  pricing  model,  as 
it  was  presented  in  Chapter  III.  An  overview  of  the  survey 
study,  the  survey  sample,  survey  responses,  the  questionnaire, 
results  of  the  analysis  of  survey  responses,  statistical 
inferences,  and  a  practicability  analysis  was  provided. 

The  next  chapter  answers  the  research  questions  and 
renders  conclusions  and  recommendations. 
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V.  CONCLUSION 


A.  PURPOSE 

The  purpose  of  this  chapter  is  to  answer  the  research 
questions  and  render  conclusions  and  recommendations. 

B.  ANSWERS  TO  RESEARCH  QUESTIONS 

This  section  will  answer  the  research  questions  that  were 
stated  in  Chapter  I . 

1 •  Primary  Question 

a.  What  is  the  Practicability  of  Developing  a 
Standard,  Stand-alone,  Computerized  Contract 
Pricing  Model  That  Will  be  Used  as  a  Decision 
Support  System  for  Contract  Pricing  and 
Negotiations? 

Developing  a  standard,  stand-alone,  computerized, 
contract  pricing  model  that  will  be  used  Navy-wide  as  a 
decision  support  system  for  contract  pricing  and  negotiations 
does  not  seem  practicable. 

The  technology  exists  and  it  is  feasible  to 
develop  the  proposed  model.  However,  programming  constraints, 
due  to  cost  element  and  cost  accounting  system  diversity,  and 
flexibility  requirements,  would  render  the  model  too  complex 
and  it  would  probably  not  be  used. 

Additionally,  since  not  all  activities  utilize  the 
same  brands  of  software,  writing  the  proposed  model  for  a 
particular  brand  of  software  would  prevent  some  activities 
from  employing  the  model. 
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Furthermore,  a  model  is  not  always  necessary. 
Small  purchase  activities  would  have  limited  application  for 
pricing  models  due  to  the  nature  of  small  purchasing. 

Therefore,  a  Navy-wide  standard,  stand-alone, 
computerized  contract  pricing  model  is  not  practical.  Such  a 
model  at  the  activity  or  organizational  level  has  its  merits. 

2 .  Subsidiary  Questions 

a.  Do  DLA,  Navy  or  Marine  Corps  Field  Contracting 
Offices  Currently  Have  Computerized  Contract 
Pricing  Models  That  They  are  Using? 

Yes.  Currently,  one-half  of  the  74  activities 

that  responded  to  the  survey  are  using  computerized  contract 

pricing  models.  Some  activities  use  more  than  one  model 

because  of  contractor  or  contract  differences. 

b.  Do  Defense  Contractors  Currently  Have  Computerized 
Contract  Pricing  Models  Within  Their  Companies 
That  They  are  Using? 

Yes.  Most  major  defense  contractors  have 
computerized  contract  pricing  models  that  they  use  for  both 
pricing  and  during  negotiations. 

Currently,  some  field  contracting  activities  are 
simply  giving  the  contractors  floppy  disks  and  having  price 
proposals  submitted  by  the  contractors  on  floppy  disks  that 
include  a  workspace  for  the  Government  field  contracting 
activity  to  enter  its  objective  position  and  another  workspace 
for  use  during  negotiations. 


All  of  the  defense  contractors  that  were  contacted 
use  either  a  computerized  pricing  model,  computerized 
spreadsheets,  or  both. 

c.  What  Elements  Should  Comprise  a  Standard,  Stand¬ 
alone,  Computerized  Contract  Pricing  Model  and 

What  Functions  Should  it  Perform? 

The  proposed  model  is  comprised  of  three  major 
systems — calculate  the  Government's  price  proposal,  calculate 
the  contractor's  price  position,  and  calculate  the  negotiated 
price  position. 

Each  of  these  three  major  systems  is. comprised  of 
five  subsystems — calculate  direct  materials,  calculate  direct 
labor,  calculate  other  direct  costs,  calculate  indirect  costs, 
and  calculate  profit. 

The  calculation  of  direct  materials  is  performed 
by  five  subsystems — calculate  raw  materials,  calculate 
subcontracted  items,  calculate  standard  items,  calculate 
interorganizational  transfers,  and  calculate  purchased  parts. 

The  calculation  of  direct  labor  is  performed  by 
two  subsystems — calculate  factory  labor  and  calculate 
engineering  labor. 

Calculation  of  other  direct  costs  is  performed  by 
an  unprescribed  number  of  subsystems.  Some  examples  include — 
tooling,  operating  expenses,  tires  and  tubes,  oil  and  grease, 
and  equipment  rental. 

Calculation  of  indirect  costs  is  performed  by  an 
unprescribed  number  of  subsystems  also.  Indirect  cost 
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accumulation  pools  include,  but  are  not  limited  to — material 
overhead,  factory  overhead,  engineering  overhead,  and  general 
and  administrative  costs. 

Calculation  of  profit  is  performed  by  two 
subsystems — the  weighted  guidelines  method  and  the  profit  base 
method. 


C.  CONCLUSIONS  AND  RECOMMENDATIONS 

The  conclusions  and  recommendations  that  were  derived  from 

the  survey  data  and  the  practicability  analysis  follow: 

That  a  collective  opinion  among  DLA,  Navy,  and  Marine 
Corps  field  contracting  activities  exists; 

That  there  is  a  necessity  for  computerized  automation  in 
developing  price  proposals  and  for  use  during  price 
negotiations; 

-  That  the  hardware  and  software  technology  exists  to 
develop  the  proposed  model; 

That  it  is  feasible  to  develop  the  proposed  model; 

That  there  is  not  a  desire  or  a  need  for  a  single  agency/ 
service-wide  standard,  stand-alone,  computerized  contract 
pricing  model ; 

That  it  is  not  practical  to  develop  the  proposed  model 
Navy-wide ; 

That  the  Navy  should  not  invest  scarce  resources  in  the 
development  of  the  proposed  model; 

-  That  the  proposed  model  at  the  activity  or  organizational 
level  has  its  merits; 

That  the  expertise  exists  to  develop  computerized 
contract  pricing  models  in-house  at  DLA,  Navy,  and  Marine 
Corps  field  contracting  activities; 

That  there  is  a  preferred  software  used  by  DLA,  Navy,  and 
Marine  Corps  field  contracting  activities; 


That  Navy-wide  software  standardization  warrants 
consideration . 

D.  SUMMARY 

This  chapter  answered  the  research  questions  and  rendered 
11  conclusions  and  recommendations. 
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